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1 Uberblick 

Die vorliegende Spezifikation spezHiziert das Softwarewerkzeug BAUDIS NET. 

BAUDIS NET soil die gesamte Funktionalitat. die zur Konfiguration, Bedlenung. Diagnose 
und Inbetriebnahme von einer groBen Anzahl von Antrleben notwendig ist. umfassen. 

Urn die wesentliohen Anfordemngen zu definieren. die bei der Entwicklung von BAUDIS NET 
b^SSSden wird im Kapitel 3 eine umfassende Analyse der Anfordemngen 

Sora^omr^^^^ die Anforderungen an BAUDIS NET aus der Steht eines En6- 

Sen Ts HauS^ und der Sicht der Fa. BaumQIIer analyslert. Zus^men mit 

den Bnsch'al^^^^^^^^ die bestehenden Softwarewerkzeuge Baud.s und Baudis pro 

unterllegen, kdnnen wesentliche Eckpunkte der Softwarestruktur spezifiziert werden. 

Aufbauend auf der Anfordemngsanalyse in Kapitel 3 wird In Kapitel 4 das Gesamtkonzept Wr 
BMl^^nilspeSn ist eine komponentenbasierte und enjvert^^^^ 

rastruktur die mrt Hilfe von flexiblen Funktionen zur Diagnose ^^^J^^^^^^'Z^J^^^^ 
zung eniveltert werden kann. Zum Abschluss des Kapitel 4 werden wichtige Vorteile der 
Sof^areslruklur von BAUDIS NET aus der SIcht des Kunden aufgelistet. 

Das Kapitel 5 belnhattet die technische Spezifikation der Bedienoberflachen M» J? ^^r 
Unffied Modeling Unguage (UML) werden die fQr die in den vorausgehenden Kapitelryiot- 
weXVFunSinen detln spUzlert. Auf der Grumllage dieser Sp««f jl^Jo^^^ 
Oberfllchenprototyp in Microsoft PowerpoInt erstellt. Er soli zur Optlmierung der Bedien- 
-obeS^ Kesigns als-Olskussionsgrundlage-fOrdie- E-nfuhrung weiterer 

Funktionen dienen. 

Das Kapitel 6 spezifiziert die Architektur des BAUDIS NET Application Servers. HierfQr_ wer- 
den K Kapitel 5 spezrflzierten Funktionen mIt Hllfe von UML beschrieben und eln objekt- 
orlentlerter Entwurf erstellt 

ofe'^voSnde Spezifikation wird bis zum Abschluss der Spezifikationspfiase ftandig Qbei^^^ 
a beitet und enwertert. Sie stellt den Wissensstand und die Planungen zum Zertpunkl der 
iSung dar.X Aussagen In den Kapltein 3 und 4 (Anfordemngsanalyse und Gesamt- 
konzept)^^^^^^^^ betrachten'. DIese werden fur die Genehmigung des Projekte 

ate wesentlich angesehen. Die Aussagen in den Kapltein 5 und 6 (Bedienoberflachen und 
Application Server) k6nnen noch verSndert und erganzt werden. 
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2 Definition wichtiger Begriffe 



Ereignis 



Ein Ereignis ist eine Information die von einem Antrieb beinn Auftreten an 
den BAUDIS NET-Server gesendet wird. Es ersclieint in der Ereignisan- 
zeige der BedienoberflSche und im Logbucti. Ereignisse sind z.B. Feli- 
lermeldungen, I^eldungen uber den Start/ Stop von Aufzeiclinungen, 
Wartungsmeidungen etc. Jedes Ereignis liat eine eindeutige Ereignis- 
i<ennung Qber die eine Ereignisbeschreibung In der Dokumentation abge- 
rufen werden kann. 

Mit einer Aufzeichnung kann man beliebige Parameterverlaufe von belie- 
blgen Reglern erfassen und In einer Datenbank speichem. 

Die Obenwachungsanslcht Ist eine graphische Darstellung eines oder 
mehrerer Parameter von einem oder meiirerer Regler. Sle dient dazu, 
den Werteverlauf dieser Parameter hinsichtlich Abwelchungen von der 
Norm zu Obenwachen. (z.B. Obenwachung der Motortemperatur) 

Parameteriiste Die Parameterliste entiiatt alle an einem Reglertyp vorhandenen Para- 
meter 

Parametergruppe Eine Parametergruppe fasst meiirere Parameterseiten zusammep und 
benennt diese mit einem Namen und einem Kommentar 



Aufzeichnung 



Oberwaciiungs- 
anslcht ' 



Parameterseite 



Langzeitauf- 
zeichnung 

Ringspeicherauf- 
zeichnung 



Konfigurations- 
Wizard 



Eine Parameterseite ist Tell einer Parametergruppe und enthSIt mehrere 
Parameter von bellebigen Reglern. 

Eine Aufzeichnung, deren Daten auf dem BAUDIS NET Server In einer 
Datenbank gespetehert werden. Gegenteil zur RIngspeicheraufzetehnung 

Eine Aufzeichnung, deren Daten im RIngspelcher des G-Drives gespei- 
chert werden. Erst nach Beenden der Aufzeichnung kdnnen die Daten 
auf dem BAUDIS NET Sender gespeichert werden. 

Eine Abfolge von einzelnen Seiten auf denen der Benutzer Einstellungen 
vornehmen kann. Jeder Schritt in der Konfiguration umfasst eine Anzahl 
von FunkHonen und wIrd auf einer Seite dargestellt. Je nachdem wie der 
Benutzer sich im vorherigen Schritt verhalt, wird eine entsprechende 
Nachfolgeseite angezeigt (z.B. bei Konfiguration der Aufzeichnung: 
Auswahlmdglichkeit Im Schritt 1: Ringspeicher oder Langzeitaufzeich- 
nung: Je nach Auswahl bekomml der Anwender Seiten fur die Konfigura- 
tion des RIngspeichers oder der Langzeitaufzeichnung angezeigt.) 
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3 Anforderungsanalyse 

An die Entwicklung einer modemen Software werden hinsichtlich Struktur und Funktlon zahl- 
reiche Anforderungen gestelft. Vorraussetzung fiir eine zukunftssichere Softvy/arearchitektur 
ist eine sorgfaitige Analyse der spezifischen Anforderungen und Funktionen. die die zu ent- 
wickelnde Software erfOllen soil. Die folgenden Kapitel geben eine Ubersicht. uber die an die 
Entwicklung von BAUDIS NET gestellten Anfordemngen. Zunachst werden in Kapitel d.i 
allgemeine Anforderungen aus der Sicht des Endkunden betrachtet. P'ese werden prazisiert 
durch Kapitel 3.2, welches einen Auszug aus einer „Wunschliste« des Hauptkun^en MAN 
enthalt. Zusammen mit den Anforderungen der Fa. BaumQIIer in Kapitel 3.3 erQibt sich ein 
umfassendes Anforderungsprofil fur die Entwicklung von BAUDIS NET. Die weltere Vorge- 
herisweise bel der Speziflkation wird in Kapitel 3.5 eriautert. 

3.1 Allgemeine Anforderungen aus der Sicht des Endkun- 
den 

Ziel der Entwicklung von BAUDIS NET Ist es. ein Softwareweri<zeug zu entwickein das auf 
die Anforderungen und BedQrfnisse des Endkunden zugesohnWen Ist. Aus der Sicht cjes 
Endkunden ergab die Analyse folgenden Anforderungen: 



(1) Flexible Funktionen zur Oberwacliung und Diagnose groBer Antriebssystenie 

Ziel des Projekts .BAUDIS NET ist die Entwicklung eines Softwarewerkzeugs zur Uberwa- 
chung und Diagnose von groBen Antriebssystemen. BAUDIS NET soli umfangreiche. flexible 
Funldionen bieten, die auf die z.T. sehr unterschiedllchen BedOrfnlsse der verschiedenen 
Benutzergruppen beim Kunden zugeschn'itten sind. 

(2) Einfacli zu l>edienende, Qbersichtliolie Bedienoberflaclie 

Die Bedienoberfiache von BAUDIS NET ist der einzige Tell der Software, mit der der Kunde 
In Kontakt kommt. Insofem Ist sle das ./^ushangeschiid" der Software und fur deren Akzep- 
tanz und Beurteilung von Serten des Kunden entscheidend. 

Beim Entwurf der Bedienoberfiache ist darauf zu achten, dass sle auch fOr wenig geschultes 
Personal lelchl zu bedlenen Ist. Die Vielzahl der bel der Diagnose von groBen Anlagen anzu- 
zeigenden Informationen mussen graphlsch aufbereitet werden und In einer ergonomischen 
Darstellung dem Anwender prasentiert werden. 

(3) VerlcQrzung der zur Auffindung eines eventuelien Fetilers notwendigen Zeit. 

Der Nutzen von BAUDIS NET soli fQr den Kunden darin llegen. dass er sofort nach dem 
Auftreten eines Fehlers Im Antriebsystem die fQr die Auffindung und Behebung des Fehlers 
notwendigen Infomiationen prasentiert bekommt. Hierdurch kann die Zeit In der die Aniage 
nicht produktiv ist, reduziert werden. 

(4) Situationsabhangige Darsteliung von Diagnose-lnformationen 

BAUDIS NET soli die richtige Information zum richtigen Zeltpunkt am richtigen Ort zur VertQ- 

Qunci stellen: . 

. Aufbereitung der Diagnose-Informatlon gemaB den Anforderungen des jeweiligen 
Benutzerkreises (z.B. Aniagenbediener, Techniker, Inbetnebnehmer) die rich- 
tige Infonmation) .. « ^ » x et-^k 

• Zeitnahe Anzeige von Diagnose-lnformationen direkt nach Auftreten eines Feh- 
lers zum richtigen Zeitpunkt) . »„*r- - rf- 

• Zugrlff auf BAUDIS NET von bellebigen PCs des Kunden ohne Installatronsauf- 
wand - sowohl im lokalen Kundennetz als auch Ober Fernzugriff. (-» am richtigen 
Ort) 
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(5) Reduzierung von kritlschen Aniagenzustanden durch vorbeugende Wartung und 
standige Oberwachung der Aniage x » u 

Zukunftig soil BAUDIS NET Mechanismen beinhalten, die dazu beitragen, eventuell bevor- 
stehende AusfSlle von Geraten vorab zu erkennen und dem Kunden mitzutellen. So kann die 
Zuveriasslgkelt des Antrlebsystems welter erhSht warden. 

3.2 Anforderungen des Hauptkunden (MAN) 

Die nachfolgende Aufzahlung beinhaltet konkrete Punkte, die von Seiten des Hauptkunden 
MAN fur ein zukunftssicheres Antriebssystem gewQnsoht werden. Die folgenden Punkte 
wurden wortllch aus der ..Wunscliliste" Qbemommen: 

(1) Umfassende Diagnose- / Messfunktionen via schneller Ethernet-Sohnlttstelle unter Ein- 
bezlehung des Ethernet-Gesamtkonzeptes der Maschine urn z.B. das Referenzslgnal der 
realen Leitachse zu messen, aufzuzeichnen und auszuwerten 

(2) Vorbeugende Diagnose (z.B. Geberausfall in .„ Tagen walirsolielnllch) 

(3) ..Expertensystem" soli Fehlerlokaiisiemng innerhalb max, 10 min sicherstellen und 
Fehlerbehebung wesentlich vereinfachen 

(4) Webbrowser-Funktionen 

(5) Das Diagnosesystem muss auf mehreren Platlformen laufen k6nnen (z.B. MRA- 
Leltstand) 

(6) Integrierte Datenprotokollierung / -analyse (Registenwerte, Kommandos) nnuss ohne zu- 
satzliohe Hardware (Datenanalyzer) verfOgbar sein 

(7) Zyklische Datenprotokollierung auf zentralen Datenbankserver 

(8) Zugriffsm6gllchke!t fOr den Maschinenhersteller auf ausgelieferte Antriebssysteme per 
Femdiagnose 

(9) Bedlenerfulirung und Parameteriiandiing (Konfiguratfon, Inbetriebnahme, Fehlersuche, 
Software-Updates) sind wesentlich zu verbessern 



3.3 Anforderungen der Fa. Baumuller . 

Aus der Sicht der Fa. Baumuller Anlagen-Systemlechnik bestehen einer Reihe von Anforde- 
rungen, die bei der Entwicklung von BAUDIS NET bertJcksichtigt werden sollen: 

(1) Ausbau der Kompetenz im Bereich der Aniagendiagnose und - Qberwachung 

Die Fa. BaumQIIer Aniagen-Systemtechnik besitzt mit den Produkten Baudis und Baudis pro 
langjahrlge Erfahrung auf dem Geblet der Femdiagnose und -Qbenwachung von Antrieb- 
systemen. Bereits das bestehende Produkt Baudis und Baudis pro stellt eIn Alleinstenungs- 
merkmal gegenQber anderen Antriebshersteller dar. Durch die Entwicklung von BAUDIS 
NET soil diese Kompetenz weiter ausgebaut werden und so die Weittbewerbsfahigkeit ge- 
genQber den Mitbewerbem erhSht werden. Insbesondere sollen alie bishengen Funktionen in 
den Softwarewerkzeugen Baudis und Baudis pro aucH In BAUDIS NET enthalten sein. 

(2) BerQckslchtigung der WOnsche von MAN 

Als Hauptkunde kann die MAN die BerOcksichtigung ihrer WQnsche im Bereich der Aniagen- 
diagnose und -uben/vachung erwarten. 
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(3) Entwicklung von branchenubergreifenden Losungen 

Trotz Beruckslchtigung der Wunsche der MAN soli BAUDIS NET fflr den branchenubergrei- 
fenden Einsatz entwickelt werden, so dass ein EInsatz In anderen Branchen (z.B. .Werk- 
zeugmaschinen) ohne groBen Aufwand mogllch ist. 

(4) Bereitstellung der Softwarewerkzeuge fQr die Inbetriebnahme von Antriebssyste- 
men mit zukQnftig bis zu 500 Achsen 

Antriebssysteme mIt mehr ats 300 Achsen sind ohne Softwareunterstutzung nur noch mit 
unverhaltnismaBig hohem Aufwand in Betrieb zu nehmen. Hierfur soli mit BAUDIS NET ein 
geeignetes Softwarewerkzeug entwickelt werden. 

(5) VerkOrzung der Inbetriebnahmezeit und Reduzierung der inbetrlebnahmekosten 

Mit Hilfe von BAUDIS NET sollen die Kosten fur die Inbetriebnahme durch die Bereitstellung 
geelgneter softwaregestOtzter Verfahren langf ristig reduziert werden. 

(6) Weltweiter Zugriff auf das Antriebssystem zur schnellen und kostengunstlgen Di- 
agnose 

Fur einen schnellen und zuverlassigen Service und zur Aniagendiagnose soil ein weltweiter 
Zugriff auf das Antriebssystem moglich sein. 

(7) ErschlieBung neuer DIenstleistungen zur Aniagendiagnose und -uberwachung 
BAUDIS NET kann Grundlage fQr die ErschlieBung neuer Servlce-Dienstleistungen seln. 
Z.B. konnen mit geringem Personalaufwand viele groBe Aniagen hinsichtlich Zustand Qber- 
wacht werden und im Fehlerfall entsprechendes Servicepersonal ihfornriiert werdenr 



3.4 Einschrankungen von Baudis und Baudis pro 

Die belden Diagnosewerkzeuge Baudis und Baudis pro werden seit einlgen Jahren erfolg- 
reich eingesetzt. Die hier gewonnenen Funktionen und Erfahrungen sollen auch in BAUDIS 
NET zur Verfugung stehen. Leider ist jedoch die Baudis und Baudis pro zu Grunde liegende 
Softwarestruklur als Basis fQr die Erfullung obengenannter Anfordemngen nicht.geeignet Im 
folgenden werden die In Baudis und Baudis pro enthaltenen, strukturimmanenten Einschran- 
kungen aufgelistet, die eine Weiterentwicklung der beiden Softwarewerkzeuge, so dass sie 
die obengenannten Forderungen erfullen kdnnen, nicht sinnvoll erschelnen lassen: 

• Die Bandbreite fiir die Datenubertragung (RS485 Schnittstellen) reicht nicht aus. Die auf 
der Bedienoberfiache darzustellenden Infomiationen kdnnen aufgrund der Ring- 
Kommunikationsstruktur nicht schnell genug ubertragen werden. Die Abfrage eines Pa- 
rameters dauert 50 -60 ms ^ be! Aniagen mit ca. 500 Antrieben wurde z.B. ein anste- 
hender Fehler erst nach mehr als einer Minute angezelgt werden. 

• Jeder Parameter wird einzein ubertragen - Die Obertragung von Parameterpaketen ist 
nicht mSglich 

• Zur Visual-Basic-Bedienoberflache: 

• erfordert Installation 

• Updates sind schwierig durchzufQhren • 

• Nicht plattformunabhangig 

• Auflosung von 800 X 600 Ist fest . . 

• Das AnIagenbild passt nicht auf eine Seite 

• Kein zuverlSssiges Backup des Reglerzustands moglich (Firmware und Datensatze). 

• KeIn Softwareupdate fur den G-Drive moglich 
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• Keine gleichzeitige Behandlung von Antriebsgruppen 

. Die Unterstutzung bestimmter Sprachen bendtigt eine Umschaltung der Betriebssystem- 
sprache 

• Die arideren Regler der BaumQIIer ReglerfamIHe werden nicht unterstOtzt. 

3,5 Schlussfolgerungen 

Die Ausfuhrungen in den Kapltein 3.1, 3.2 und 3.3 zeigen. dass an die Strulctur von BAUDIS 
NET umfangrelche und vielfaltige Anforderungen gestellt werden mussen. Insbesondere ist 
es notwendlg sehr flexibel und mit verhaitnismaBigem Aufwand auf die Anforqierungen des 
Kunden reagieren zu konnen. Zusatzlicli ist heute noch nicht abzusehen. welohe Funktionen 
zukQnftig bei der Diagnose vom groBen Antriebssystennen vom Kunden gewunscht werden. 
Dies bedingt, schon beim Entwurf der grundlegende Struktur der Software darauf zu achten, 
dass eine standardlsierte. flexible Stmklur entsteht. die leiolit durch neue Funktionen erwei- 

Um df^emliohen Anspruch gerecht zu werden, igrsclieint eine Auttellung des Aufgabe in 
zwei Schritte sinnvoll: 

(1) Schaffung einer zukunftssicheren Infrastruklur fQr die Aniagendlagnose und lnb#trleb- 

(2) iS'Sliclclung von neuen Funktionen fQr die Aniagendiagnose, -QbenAfachung und Inbe- 
triebnahmeunterstOtzung. 

In den folgenden Kapitein werden die belden genannten Punkte nfiher spezlflzlert. 
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4 Gesamtkonzept BAUDIS NET 

4.1 Spezifikation wichtlger Eigenschaften von BAUDIS NET 

Im nachfolgenden Kapitel werden wichtige Eigenschaften der BAUDIS NET Infrastruktur so- 
wle wesentliche Funktionen definiert. Dabei liegen die in Kapitel 3 genannten Anforderungen 
zu Grunde. 

4.1.1 Eigenschaften der Infrastruktur 

Um eine zukunftssichere und schnelle Infrastruktur fOr die Diagnose und Inbetrlebnahme- 
funktionen von BAUDIS NET zu erzielen werden einlge Eckpunkte spezlflzlert: 

(1) Vertellte, dezentrale Inf rastruktur f Or die Aniagendlagnose und Inbetrlebnahme 

Umfangrelche Diagnosefunktionen und Funktionen zur softwaregestQtzten Inbetriebriahme 
solien mogllchst nahe am betreffenden Gerat angesledelt sein. Dies hat den Vorteil, dass 
vieie Aufgaben bei der Diagnose Und Inbetrlebnahme dezentral ohne groSe Beanspruchung 
der Server-Ressourcen zur VerfOgung stehen konnen. Die Verlagerung wesentlicher Funkti- 
onalltaten in Richtung der Regler ermSglicht eine wesentlich bessere Verarbeitung groBer 
Datenmengen. 

(2) Kommunlkatlons-lnfrastruktur baslerend auf Ethernet 

Industrlelles Ethernet ermoglicht im Verglelch-zur serleUen Kommunikation uber RS485 und . 
das USS-Protokoll eine vielfach hohere Bandbreite fur die DatenQbertragung. Weiterhin hat 
sich Ethernet fQr die Ubertragung groBer Datenmengen als weitgehender Standard durchge- 
setzl. Durch die Venwendung von Ethernet mit TCP/IP 1st die Kompatlbilltat von BAUDIS 
NET mit dem Internet gewahrleistet 

(3) Webbasierte BedienoberflSchen 

Webbasierte Bedienoberfiachen bieten aufgrund Ihrer Flexibllitat gegenQber konventionellen 
Oberflachen einige entscheidende Vorteile: 

• Die Weboberfiache kann auf belieblgen Client-Rechnem laufen (z.B. Leitstands- 

PG) 

• Eine Installation der BAUDIS NET Bedienoberflache auf dem Ciient-Rechner 

entrant . . ^ 

• WeboberfiSchen sind aufgrund ihrer welten Verbreitung durch das Intemet leicht 

bedienbar 

• Die Bedienoberflache kann mit vertretbarem Aufwand an KundenwQnsdie ange- 
passt werden 

(4) Plattform-unabhangige Serverarchltektur 

In der Anlagenautomatislerung hat sich bis Jetzl noch keine der beiden Betrrebssystemwelten 
Unux Oder Windows als Standard etabliert. FOr BAUDIS NET soil als Betriebssystem for die 
Sewerkomponenten von BAUDIS NET Linux gewahit werden. Dies bietet folgende Vorteile: 

• Unux ist ein standardisiertes, offenes Betriebsystem - Windows ist proprletar 

• Die erheblichen Lizenzkosten f Or Serversbftware unter Windows entfalien 

• Der Hauptkunde MAN setzt Unux auf den Leitstands- Rechner ein 

• Eine Portierung der Serversoftware auf Windows ist bei Venwendung von Linux 
zusammen mit Java einfach mdglich. Bei Entwicklung der Software unter Win- 
dows mit einer Sprache aus dem .NET-Framwork Ist ein Portierung auf Linux 
nicht mSglich. 

• Unux ist das meistbenutzte, zuverlassigste Server-Betriebsystem im internet 

(5) Komponentenbasierter Aufbau 
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Ein komponentenbasierter Aufbau ermoglicht die Erweiterbarkeit mit neuen Funktionen so- 
wie die flexible Anpassung an die Anforderungen anderer Branchen. Durch die konsequente 
Nutzung von objektorientierter Technologie soil ein hoher WiedervenA^endungsgrad der Soft- 
ware erreiclit werden. 

(6) Einbeziehung der Baumuller Reglerfamilie 

Die Infrastruktur von BAUDIS NET soil so entworfen werden, dass alle Regler aus der Reg- 
lerfamilie der Fa. BaumQIIer unterstQtzt werden konnen, sofern sie geeignete Schnittstellen 
fur die Obertragung der Diagnosedaten zur VerfQgung stellen. 

(7) Leichtere UnterstQtzung vieler Sprachen 

Aufgrund der Intemationalen GeschaftstStigkeit der Fa. BaumQIIer wird es gefordert die 
BAUDIS NET Bedienoberflache in verschiedenen Sprachen auszuliefern. Hierzu ist eine 
Sprachunterstutzung notwendig, die e\r\e Portierung der Bedienoberflache mit den dazuge- 
horigen Meldungen In eIne andere Sprache eriaubt. Die modernen Intemettechnologlen 
stellen hlerfQr geeignete Verfahren zur Verfugung. . 

(8) ErschlieBung des Internets fur die Aniagendiagnose 

Die Grenze zwischen dem firmenintemen Intranet und dem globalen Internet wlrd In zunehr 
menden MaBe venArfscht Gerade im Bereich der Fernwartung und Ferndiagnose wird zu- 
kunftig verstarkt die Forderung bestehen Diagnosedaten uber das Internet zu verschjoken 
Oder eine Aniagen von einem beliebigen Client Im Internet sicher zu uberwachen. Durch die 
JNutzung der Internetlechriologien wie z.B. Webselten, HTML, e-mail etc. sollen dieser zu- 
kunftigen Mogllchkeiten erschlossen werden. 



4.1.2 Wesentliche Funktionen fn BAUDIS NET 

Im Folgenden werden einige wesentliohen neuen Funktionen spezifizlert, die in BAUDIS NET 
enthalten sein sollen. Die genannten Funktionen sind In zwei Bereiche^ aufgeteilt: Neue 
Funktionen Im Bereich Inbetriebnahme und Neue Funktionen im Bereich Uberwachung und 
Diagnose. Alle In Baudis und Baudis pro enthaltenen Funktionen sollen welterhin In BAUDIS 
NET verfQgbar sein. Alle genannten FunkHonen werden In den entsprechenden KapiteIn 
waiter spezifizlert. 

Neue Funktionen Im Bereich Inbetriebnahme 

(1) Softwaregestiitztes Rrmwareupdate 

Gegensatz zum manuellen Einspielen der Rmnware auf den Regler (z.B. M-Drive) soli die 
Funktion „softwaregestutztes Firmwareupdate" ein schnelles und einfaches Bespielen der 
Regler mit der Firmware ennogllchen. Hierdurch kann besonders bei groBen Aniagen eine. 
erhebliche Zeit- und Kosteneinspamng en-eicht werden. 

(2) Sicheres Backup eines Antriebs 

Bei Arbeiten an der Konfiguratlon eines Reglers Ist eine Funktion zum zuverlassigen Backup 
eines Antriebs erforderllch. Vor der Durchfuhrung der Konflgurationsarbeiten oder einer neu- 
en Reglerfimiware kann eine Sicherung des kompletten vorherigen Antriebszustands erstellt 
werden. 

(3) Funktionen fur den automatisierten Antriebstest 

Zur Standardlsierung und Verelnfachung der Antriebstests sollen sbftwaregestOtzte Funktio- 
nen zur Verfugung gestellt warden. Z.B. sollen automatisierte Funktionsprufungen den An- 
trieb in verschiedenen Betrlebszustanden uberprufen und ein automatisiertes Pruf- und Ab- 
nahmepfptokoll erstellt werden. 

(4) Softwaregestutzte Antriebsoptimierung 

BAUDIS NET soil Funktionen zur softwaregestQtzlen Optimlerung der Reglereinstellungen 
zur VerfQgung stellen. 
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Neue Funktionen Im Bereich Diagnose und Oberwachung 

(5) Erweiterte Funktionen fur die Aufzefchnung von Parametern 

Im Gegensatz zu den bisherigen Moglichkeiten soli BAUDIS NET die Mogliohkeit bieten be- 
llebige Gruppen von Parametern von belieblgen Reglem in einer Aufzelchnung Qber einen 
festgelegten Zeitraum aufzuzeiclinen. Zusatzllch kdnnen mehrere Aufzeichnungen glelohzel- 
tig gestartet werden. 

(6) Erweiterte Funktionen fur die Visualisierung von Aufzeicfinungen Oder Parametern 
BAUDIS NET soil umfangreiche Moglichkeiten bieten Aufzeichnungen Oder Parameterver- 
laufe in verschiedenen Darstellungen zu visualisieren. 

(7) Vorbeugende Diagnose 

Wi\ Hllfe von konfigurierbaren RoutineubenA/achungen wichtiger Betriebsparameter des An- 
triebssystem soil die Zuverlassigkeit der Anlagen waiter erhoht werden. Wlchtige-Uberwa- 
chungsinformationen sollen automatisch dem zustandigen Personal weitergeleitet werden. 

(8) Wesentlich erweiterte Diagnosiemogiichkeiten zur Fehlersuche 

Durch die dezentrale Verteilung von Diagnosefunktionen sollen In BAUDIS NET wesentllch 
erweiterte Diagnosemogllchkeiten zur Fehlersuche zur VerfQgung gestellt werden. Z.B. sol- 
len sehr variable Triggerbedingungen fur die Aufzelchnung sowie Skriptunterstutzung auf 
dem dem Regier beigefugten Kommunikations-PC zur VerfQgung stehen. 



4.2 Uberblick Grobstruktur BAUDIS NET 

Ziel der Entwicklung 

BAUDIS NET soli die wesentllche Funktionalitat, die zur Konfiguration, Bedienung, Diagnose 
und Inbetriebnahmen von einer groBen Anzahl von Antrieben notwendig ist, umfassen. 
BAUDIS NET soil ein komponentebasiertes und erweiterbares System sein, um es an zu- 
kunftige Anforderungen anzupassen. 




Abbildung 4-1 : Grobstruktur von Baudls NET 
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Die obige Abbildung 4-1 gibt einen Oberblick uber die Grobstruktur von Baudis NET. Dem. 
Anwender stehen verschiedene web-basierte Bedienoberflachen zur Verfugung, die ihm die 
Funktionalitat von BAUDIS NET In einer fur ihn geeigneten Darstellung prSsentieren. Fur die 
Bedienung des Systems ist es unerheblich, ob sioli der Benutzer lokal an der Aniage Oder an 
einem anderen Ort befindet. 

Die vom Benutzer gewunscliten Funktionen werden von den Benutzeroberflachen an den 
Application-Server weitergeleitet. Hier ist jede Funktionalitat, die in der Oberflache zur Verfu- 
gung stelit, implementiert. Weiter ubernimmt der Baudis Application-Server die Speicherung 
von alien anfallenden Daten in der Baudis-Datenbank. Alle aniagenspezifischen Oaten wie 
Z.B. die Aniagenkonfiguration Oder Bauteildatenbanken, alle diagnosespezifischen Daten wie 
Z.B. Langzeitaufzeichnungen Oder Ringspeicherdaten sowie anwendungsbezogene, Daten. 
werden in der Baudis Datenbank verwaltet. 

Werden von der Steuerung oder vom Leitstand einer Druckmascliine fur die Diagnose rele- 
vante Infomiationen zur Verfugung gestellt, konnen sie durch spezielle in den Application 
Server integrierte Komponenten weiterverarbeitet werden. 

Die von der BedienoberflSche am Application-Server eingehenden Auftrage werden dprt ver- 
arbeitet und in fur die entsprechenden Regler verstandliche Befehle umgesetzt. Die Kommu- 
nikation zwischen Application Server und Kommunikations-PC mit angeschlossenem Regler 
erfolgt uber Ethernet und darauf aufsetzende geeignete Protokolle. Am Kommunikations-PC 
werden die vom Application Server empfangenen Auftrage ausgefuhrt und das Ergebnis an 
den Application Server zuruckgeschickt. 

Die Abbildung Abbildung 4-1 zeigt verscliledene Reglertypen aus der Baumuller Reglerfami- 
lie: G-Drive und b-maXX. Jedem Regler wird ein Kommunikatidns-PC zugeordnet. Urn zu- 
kOnftig auch einen b-maXX Regler in die Diagnose einbeziehen zu kdnnen, kann ein als BA- 
Cl-Einsteckkarte realisierter Kommunikations-PC in den b-maXX gesteckt werden und dar- 
uber die notwendigen Diagnosedaten an den BAUDIS NET Server geschickt werden. Dies 
ist jedoch nicht Bestandteil des vorliegenden Entwicklungsprojekts BAUDIS NET und kann in 
einem separaten Projekt realisiert werden. 

Fur Reglertypen, die keine BAQI-Einsteckkarten aufnehmen kdnnen, kann die Verarbeitung 
der Auftrage auch durch andere Mechanismen sichergestelit werden. 

Die in der Anforderungsanalyse aus Kapitei 3 genannten Anforderungen bedingen eine 
komponentenbasferte, verteilte Architektur von BAUDIS NET. GemaB den allgemeinen 
GrundsStzen der Softwareentwicklung werden die Datenerfassung die Datenverarbejtung 
ynd -speicherung und die Benutzeroberflachen moduiarisiert und voneinander getrennt. Da- 
durch wird eine Qbersichtliche und besser skaiierbare Struktur erreicht, die leicht um weitere 
Funktionalitaten enweitert werden kann. Hierdurch kann gewahrleistet werden, dass BAUDIS 
NET mit steigender Anzahl. von Antrieben „mitwachsf' (Skalierbarkeit). Durch die VenA^en- 
dung von Ethernet und TCP/IP fQr die Kommunikation zwischen den Kommunikations-PCs, 
dem Baudis Application Server und den Anwendungen steht eine wesentlich hohere Band- 
brelte zur Datenubertragung zur Verfugung. Dies resultiert in einem im Vergleich zu. Baudis 
und Baudis pro wesentlich schnelleren Diagnosesystem. 

Weiter erieichtert die komponentenbasierte Struktur den groBen Funktlonsumfang von BAU- 
DIS NET abzudecken. Fur jede Benutzergruppe kann eine eigens auf die Bedurfnisse zuge- 
schnittene Bedienoberflache entv\nckelt werden, die auf die darunter liegende Infrastruktur 
(Application Server) zugreift. 

Durch die Trennung von Bedienoberflache und Implementierung der Funktionalitat im Appli- 
cation Server konnen zukQnftig mit weniger Aufwand neue Anwendungen entwickelt werden. 
Durch Nutzung moderner Softwaretechnologien kann das Internet als weltwelt verfQgbares 
und akzeptiertes Kommunikationsmedium genutzt werden. Daniit ist es unerheblich, ob die 
ObenA/achung der Aniage lokal vor Ort oder von einem anderen Ort, wie z.B. dem Servicebu- 
ro durchgefuhrt wird. Durch die Nutzung von gangigen Intemetbrowsern fflr die Benutzer- 
oberflachen wird der Installationsaufwand belm Anwender wesentlich reduziert und die HQr- 
de fur den Anwender das Diagnosesystem zu benutzen deutlich herabgesetzt. 
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Die komponentenbaslerte Architektur ermoglicht werterhin die Unterstutzung von neu entwi- 
ckelten Verfahren zur Oberwachung und Diagnose von Antrleben, indem. neue Funktionen 
ais Komponente in den Application-Sender eingebunden warden. 
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4.3 Kundennutzen 

Das folgende Kapltel listet wesentliche Vorteile von BAUDIS NET aus der Sicht des Kunden 
auf: 

(1) Der Kunde hat durch die Weboberflache einen universellen Zugriff auf die Diagno- 
sefunktionen: 

• Die richtige Information zeitnah am richitigen Ort 

• Einfache Bedienoberfiaciie durcli Webbrowser 

• Benutzerfuhrung erieichert die Bedienung und Konfiguration 

• Die Web-Oberflache ist plattformunabhangig 

• Bedienung uber das Internet moglich, sofem gewQnscht 

(2) Der Kunde bekommt fur Ihn aufbereitete Informatlonen Qber den Zustand der An- 
lage: 

• Informationsaufbereitung in Form von graphlsche Darstellungen 

• Vorbeugende. Diagnose 

(3) Die wesentlich erwelterten Diagnosemoglfchkelten ermoglichen: 

• Enweiterte Obenwachung der Anlage 

• Einfachere Lokalislerung der Ursache Im Fehlerfall 

(4) Die Funktionen zur Inbetrlebnahmeunterstutzung ermoglichen: 

• Schnellere Inbetrlebnahme ^ Kostenreduzierung 

• ErhShte QuaFitat der Inbetrlebnahme durch def inierte und dokumentierte Abnah- 
meprotokolie 




.0 
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5 Spezifikation der Bedienoberflachen 

Verschiedene Bedienoberflichen 

Wie bereits in Kapitel 1 erwahnt. bietet BAUDIS NET die Moglichkeit verschiedene. auf die 
speziellen BedQrfnisse der Benutzergruppe angepasste. Bedienoberflachen zur Verfugung 
zu stellen. In der ersten Ausbaustufe sollen zwel verschiedene Bedienoberflachen mit ver- 
schledenen Zielrichtungen entwickelt werden. Die aus Baudis und Saudis pro bekannten 
Funktlonen soUen auch in BAUDIS NET zur Verf Qgung stehen. 

Kapitel 5.1 spezlflzlert die Bedienoberflache fQr die Aniageninbetriebnahme. -ubenwachung 
und Diagnose. Kapitel 5.2 spezifizlert eine Bedienoberflache zur Konfiguratlon der Aniage m 
BAUDIS NET. Eine weitergehende Spezifikation steht noch aus. 



5.1 Bedienoberflache fur die Aniageninbetriebnalime, - u- 
berwacliung und Diagnose 

Fur die Inbetriebnahme, Ubenwachung und Diagnose von groBen Antriebssystemen soil eine 
Bedienoberflache zur VerfOgung gestellt werden. die die dargeslellten Informatfonen gra- 
phlsoh aufbereitet dem Anwender zur VerfOgung stellt. Die DIagnose-lnfonnationen sollen 
einem breitem Benutzerkrels zur VerfOgung gestellt werden. Z.B. soil die zu entwj^kelnde 
Anwendung unter anderem auch am Leitstand einer Druckmaschlne ausgefOhrt-awerden. 
Welter kann sie eine Informationsqueile sein. mit der sich das technlsche Personal Oder das 
Management einen schnellen Oberblick Qber die Funktion der Maschlne beschaffen kann. 
sowie vom Baumuller Personal wahrend der Inbetrlebnahmephase grundlegende Konfigura- 
tlonsarbeiten durchgefOhrt werden kdnnen. Die Benutzung der Funktionen erfordem eine 

Benutzerauthentlflzierung. ....... • «/, 

Um die Informatlonen auf der BenutzeroberflSche standig aktuell zu halten, muss em Me- 
chanlsmus implementiert werden, mit dem die aktuellen Daten st§ndlg vom Server abgefragt 
werden. Nur so kann sichergestellt werden, dass der Benutzer Qber auftretenden Fehler Oder 
andere Ereignlsse zeitnah Informiert wird. 



5.1.1 Zlelgruppe 

Personal des Kunden, z.B. Drucker, Techniker etc. und das Service - und Inbetrlebnahme- 
personal der Fa. BaumOIIer Aniagen-Systemtechnlk. 

5.1.2 Mehrsprachigkeit 

Nachdem die Anwendung zur Diagnose und AnlagenObenwachung hauptsachllch vom Per- 
sonal des Kunden benutzt werden soli, 1st die UnterstOtzung von verschledenen Sprachen 
notwendig. 

5.1.3 Implementierung 

Aufgrund des breiten Benutzerkreises muss die Anwendung sehr lelcht fur viele Anwender 
zuganglich sein. Hier bietet sIch die Implementierung als Weboberflache die in einem Web- 
browser wie Z.B. Internet Explorer oder Netscape Navigator lauft an. Der Zugnff soil sowohl 
Qber das Internet als auch Qber Einwahlverbindung oder aus dem lokalen Netz moglich sein. 
Die automatlsche Akluallsierung der Oberflache muss mit Hilfe eines geeigneten Mechanls- 
mus reallsiert werden. 
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5.1.4 Benutzer-Authentlfizierung 

Die nachfolgend spezifizierten Funktlonsgruppen sind zu drei Benutzergruppen zugeordnet: 
Benutzergruppe Drucker, Benutzergruppe Techniker und die Benutzergruppe Inbetneb.neh- 
mer Die Benutzergruppe Drucker besltzt nur Zugrlff auf die fOr sle wesentiichen Funkbonen. 
Der Benutzergruppe Techniker stelien sowohl alle Funktionen der Benutzergruppe Drucker 
sQwie weitere Funktionen zur VerfOgung. Die Benutzergruppe Inbetriebnehmer besitzt vollen 
Zugriff auf alie Funktionen. . _. . „. ■ 

Die Einteilung der Benutzer in die obengenannten Gruppen ist jedoch nur ais RIchtlinie zu 
verstehen, denn es kommt in der Praxis oft vor, dass einem Benutzer temporSr oder dauer- 
haft Zugriff auf spezielle Funktionen gegeben werden soil. Dies kann durch die Erstellung 
einer neuen Benutzergruppe erreicht werden, In der die gewOnschten Funktionen freige- 
schaltet bzw. gesperrt sind. Die Funktionen zur Erstellung einer neuen Benutzergruppe ist 
vorerst nicht Tell dieser Spezifikation und soil nur von eingewlesenem Personal durchgef uhrt 
werden. 

5.1 .5 Spezlf izlerte Funktldnalltaten fur die Benutzergruppe „Drucker" 

Die nachfolgend spezifizierten Funktionen sind in Funktlonsgruppen und Funktionen grup- 
plert. Die Abblldung 5-1 zeigt ein UMU-Anwendungsfalkllagramm aus dem die wesentiichen 
BedlenfunkUonen hen/orgehen. 
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Abbildung 5-2: Anwendungsfalldiagramm fflr die Benutzergruppe „Drucker" 
SpezlftkatlonBaudisNET24 



5.1.5.1 Funktionsgruppe Sprachenauswahl 

Mit der Funktionsgruppe Sprachenauswahl kann die gewunschte Sprache iejerzeit gewShlt 
werden. Alle Webselten sollen in der gewflnschten Sprache angezeigt werden. D'e Daten 
der Aniage (wle z.B. das Aniagenbild) sollen in verschiedenen Sprachen auf dem Application 
Server zur Verftigung stehen. Folgende Aktlonen mussen moglich sein: 



5.1 .5.1 .1 Sprache auswahlen 



5.1.5.2 Funktionsgruppe Benutzerauthentlfizierung 

Die Funktioneri der Funktionsgmppe Benutzerauthentlfizierung ermoglichen elnpn Wechsel 
der Benutzeridentitat FQr den Zugriff auf die Funktionen der Benutzergruppe Drucker ist kei- 
ne personalisierte Anmeldung erforderlich. Bel Bedarf kann sle jedoch eingeschattet werden. 
Die Daten der An- und Abmeldung werden in der Datenbank gespetehert, urn spater kntlsche 
Aktlonen nachvollzlehen zu konnen. 
Folgende Aktlonen sollen moglich sein: 

5.1.5.2.1 Benutzer anmelden 

Der Benutzer kann selnen Benutzernamen und sein Passwort angeben,unTi die seiner 
Benutzergmppe entsprechenden Rechte zusammen mit der entsprechenden Benut- 
zeroberflScKe zu erhalten,.. . _ . 

5.1.5.2.2 Benutzer abmelden 
Der Benutzer metdet sich ab. 



5.1.5.3 Funktionsgruppe Logbuch 

Mit Hilfe der Funktionsgmppe Logbuch sollen alle an den Antrieben auftretenden Ereignisse 
aufgezeichnet werden. Mit komfortablen Such- und Filterfunktionen konnen die Informatio- 
nen des Logbuchs nach vorgegebenen Kriterien durchsucht, sortiert und angezeigt vj^rden 
Zusatzlich tenn eine Beschreibung des Ereignlsses angezeigt werden. Folgende Aktlonen 
mOssen mdglich sein: 

5.1.5.3.1 Logbuch ansehen 

Das Logbuch spelchert die aufgetretenen Ereignisse. Folgende Infomiationen sollen 
angezeigt werden: 
Erelgnistyp 
Erelgnis kommt 
Erelgnis geht 
Antrieb 

Erelgnls-Nummer 
Meidung 
Betriebsart 

Maschinengeschwindigkeit 
Sicherhalt? 
Reglerfreigabe? 

5.1 .5.3.2 Logbuch filtern und sortieren 

Das Logbuch soil nach folgenden Kriterien gefiltert oder sortiert werden: 
• Rltern nach Antrieben 
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• Filtern nach Ereignistypen 

• RItem nach Datum und Uhrzeit 

5.1.5.3.3 Logbuch drucken 

Das Logbuch soli entweder gefiltert oder sortiert oder im ganzen in einem tabellari 
schen Textformat auf dem Standarddrucker ausgegeben werden konnen. 



5.1 .5.4 Funktionsgruppe Ereignisanzeige 

In der Funktionsgruppe Ereignisanzeige werden dem Benutzer die aktuellen Ereignisse (z.B. 
Fehler) tabellarisch angezeigt. Von hier aus kann er eine Beschreibung des aufgetretenen 
Ereignisses abrufen. Einige Ereignisse, z.B. solche, die nicht am Leitstand quittiert werden^ 
mQssen vom Benutzer quittiert werden, so dass sie aus der Ereignisanzeige verschwinden. 

5.1 .5.4.1 Ereignis quittieren 

Das Ereignis wird quittiert und versohwindet aus der Ereignisanzeige. 



5.1.5.5 Funktionsgruppe Anlagenbild 

In der Funktionsgruppe Anlagenbild bekommt der Anwender elnen graphischen Oberblick 
uber die Aniage prSsentiert. l-lierbei sind verschiedene graphische Ubersichten vorgesehen, 
die bei Bedarf enveitert werden konnen. Grundsatzlich solien die anzuzeigenden infomiatio- 
nen in drei Ebenen eingeteilt werden: 

1. Ebene: Aniagenebene 

In der Aniagenebene erhalt der Benutzer einen Oberblick uber die gesamte Aniage. Hier ste- 
hen ihm in der ersten Ausbaustufe zwei verschiedene Ansichten zur Verfugung: In einer Ge- 
samtdarstellung kann die gesamte Aniage in Form einer an die Realitat angelehnte Symbol- 
darstellung betrachtet werden. Diese Ansicht wird „Anlagenubersicht" genannt. In einer 
zweiten Ansicht bekommt der Benutzer einen Oberblick Qber die Struktur des Antriebssy- 
terns. Diese Ansicht wird ,Antriebssystem" genannt. 

Grundsatzlich kann der Benutzer von der Aniagenebene aus durch Klicken auf eines der 
Symbolelemente in die darunterliegende Antrlebsgruppen-Ebene springen. 

2. Ebene: Antriebsgruppen- Ebene 

In der zweiten Ebenen bekommt der Benutzer verschiedene Ansiciiten zur Auswahl ange- 
boten, die sich auf die jeweils gewahlte Antrlebsgruppe beziehen. In der ersten Ausbaustufe 
werden hier Diagnose-lnformationen zu einer Antriebsgruppe, wie z.B. Strome, Temperatur 
und Geschwindigkeit angezeigt. Zusatzlich konnen von hier aus weitere Diagnosefunktionen 
aktiviert werden. (siehe z.B. Kapitel 5.1 .5.5.2) Weitere Ansichten sind konf igurierbar. 
Von dieser Ebene aus konnen die Ansichten der 3. Ebene aufgerufen werden. 

3. Ebene: Antriebsebene 

In der dritten Ebene bekommt der Benutzer verschiedene Ansichten zu einem einzelnen An- 
trieb prasentiert. Je nach Typ des Gerates werden entsprechende Ansichten zur Verfugung 
gestellt. Beispieie fQr die verschiedenen Ansichten kdnnen dem Oberflachenprototyp ent- 
nommen werden. 



5.1.5.5.1 Anlagenbild navigieren 

Mit dieser Funktlon kann in den oben genannten Ebenene navigiert werden. 
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5. 1 .5.5.2 Oberwachung. fur eine Antriebsauswahl starten 

Mrt dieser Funktion kann fQr eine Antriebsgruppe eine kontinuierliclie Ubenwachung 
festgelegter Parameter gestartet werden. Wetteres hierzu findet sich in Kapitel 5,1.5.6. 



5.1.5.6 Funktionsgruppe ObenA^acliung 

Mit Hilfe der Funktionsgruppe Obenwachung soil der Drucker wichtige Parameter von einem 
Oder einer Gruppe von Antrieben visualisieren konnen. Dabei stehen \hm eine Auswahl von 
vordefinierten Oberwachungsansichten zur Verfugung, die er mit Hilfe des Kontextmenus 
und der AkMon 5,1.5.5.2 aufrufen kann. Folgenden Obenvachungsansichten sollen mlndes- 
tens zur Verfugung stehen: 

• . Motortemperatur . . 

• StrSme 

• Geschwindlgkeit 

Foigende Aktfonen mQssen mdglich sein: 

5.1 .5.6.1 Auswahl einer Ubenwachungsansioht 

Der Anwender wahit eine vordefinierte UbenA/achungsanslcht aus. EIn Fenster wird 
geoffnet, in dem die ausgewahlten Informationen in Form eines xy-Plots dargestellt 
werden. Die Graflk wlrd in vordefinierten Abstanden standig aktuallsiert. de nach der 
Ahzahl der ausgewahlten Antriebe werden ein Oder mehrere Graphen im:xy-Plot dar- 
gestellt. 

5.1 .5.6.2 Oberwachungsansicht speichem 

Der Benutzer kann die gesamten seit dem Start der Obenwachungsansicht angefalle- 
nen Daten als Date! abspeichern. Die Daten werden im Standardformat fur Aufzeioh- 
nungen abgespeiohert. 

5.1 .5.6.3 Oberwachungsansicht drucken 
Druckt die aktuelle Oberwachungsansicht. 

5.1.5.6.4 Oberwachungsansicht off line schaiten 

Unterbricht die Aktualisierung der UbenA^achuhgsansicht Dies wird z.B. beim Drucken 
ben6tigt. 

5.1.5.6.5 Obenvachungsansicht beendet 

Beendet die Aktualisierung der Oberwachungsansicht und schlieBt das Fenster. . . 



5.1.5.7 Funktionsgruppe Aufzeichnung 

In der Funktionsgruppe Aufzeichnung kann der Drucker aus einer Liste mit vorkonfigurierten 
Aufzeichnungen wahlen und diese Starten und Stoppen. Zusatzlich bekommt er angezeigt, 
welche Aufzeichnungen gerade aktiv sind. Foigende Aklionen sollen mogllch seIn: 

5.1.5.7.1 Aufzeichnung auswfthlen 

Der Anwender wahIt aus einer Uste eine Aufzeichnung aus, die er starten oder been- 
den will. • • • 

5.1.5.7.2 Aufzeichnung starten 
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Der Anwender startet die ausgewahlte Aufzelchnung, Dabei konnen nur solche Auf- 
zeichnungen gestartet werden, die nicht schon laufen. 

5.1 .5.7.3 Aufzelchnung stoppen und speichern 

Der Anwender beendet eine iaufende Aufzeiclinung und speicliert sie in der Datenbank 
ab. 



5.1.5.8 Funktionsgruppe Dokumentation 

In der Funktionsgruppe Dokumentation hat der Anwender Zugriff auf alle verfugbaren Doku- 
mente. Die Dokumentation zu den einzelnen Aniagenteilen, die Fehlermeldungen und Servi- 
cebeschreibungen sind in der Baudis Site abgelegt. HIer kann er in den Dokumenten navi- 
gieren und suchen. Zu den Fehlerbesohreibungen kdnnen belieblge Kommentare hinzuge- 
fQgt Oder geldscht werden. Folgende Aktionen sollen mdgllch sein: 

5.1 .5.8.1 in Dokumentation navigieren und suchen 

Der Anwender navigiert in den verschiedenen Dokumenten. 

5.1.5.8.2 Ereignisbeschreibung anzeigen 

Der Anwender lasst sich zu einem Ereignis mlt einer Ereignisnummer eine Beschrei-. 
' bung ahzeiqen. 

5.1 .5.8.3 Kommentar zu einer Ereignisbeschreibung hinzufOgen 

Der Anwender fugt einen Kommentar zu einer Ereignisbeschreibung hlnzu Oder er- 
ganzt einen bestehenden. 

5.1 .5.8.4 Kommentar zu einer Ereignisbeschreibung loschen 

Der Anwender ioscht einen Kommentar. Dies kann jeder Anwender mlt jedem Kom- 
mentar tun, ein Passwortschutz ist nicht vorgesehen. 



5.1.6 Spezifizierte Funktlonalitaten fur die Benutzergruppe „Techniker" 

Die nachfolgend spezifizierten Funktionen sind in Funktionsgruppen und Funktionen gaip- 
piert und speziflzieren die Aktionen, die die Benutzer der Benutzergruppe Techniker ausftih- 
ren konnen. Jeder Benutzer der Benutzergruppe Techniker erbt alle Funktionen der Benut- 
zergruppe Drucker. 

Die Abbildung 5-3 zeigt ein Anwendungsfaildiagramm aus dem die vorgesehenen Bedien- 
funktionen hervorgehen. Zusatzlich zu den in dleser Abbildung genannten Funktionen stehen 
dem Techniker alle Funktionen aus Abbildung 5-2 zur Verfugung. . 
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5.1. 6,1 Funktionsgruppe Logbuch 

Die Funktionsgruppe Logbuch ist bereits in Kapitel 5.1.5.3 besohrieben. Zusatzlich zu den 
dort genannten Funktionen kann der Techniker das Logbuch In eine Date! auf dem Client- 
Rechner exportieren und nicht mehr benotlgte Logbucheintrage archivieren. Folgende Aktio- 
nen sollen moglich sein: 

5.1 .6.1 .1 Logbuch exportieren 

Das aktuell angezelgte Logbuch wird in eine Datei auf dem Clientrechner geschrieben. 
Dabei kann as sich um das komplette Logbuch oder um einen mit Htife der Filterfunkti- 
on reduzierten Teil des Logbuchs handein. 

5.1.6.1.2 Logbuch archivieren 

Um die LSnge des Logbuchs zu begrenzen, kann der Techniker nicht mehr bendtigte 
Eintrage flltern und archivieren. Nach dem Archivieren von EintrSgen werden diese. im 
Logbuch nicht mehr angezeigt. 



5.1.6.2 Funktionsgruppe ObenA^achung 

Die Funktionsgruppe Ubenvachung ist bereits in Kapitel 5.1 .5.6 beschrieben. Zusatzlich zu 
den dort genannten Funktionen kann der Techniker fur alle Benutzer* von BAUDIS NET neue 
OberwacTiungsansichten erstellen, vorhandene editieren und Idschen. Die stahdardmaBig 
vorhandenen Oberwachungsansichten aus Kapttel 5.1.5.6 kdnnen weder editlert noch ge- 
loscht werden. Will der Anwender eine dieser Obenwachungsansichten verSndem muss er 
diese kopieren und danach editieren. Folgende Aktionen sollen moglich sein: 

5.1 .6.2;1 Uberwachungsansicht erstellen 

Der Anwender erstellt eine neue Oberwachungsansicht. Hierbei wird ein Konfigurati- 
onswizard aufgerufen, der die notwendigen Informationen vom Benutzer abfragt. 

5.1 .6.2.2 Uberwachungsansicht kopieren 

Um eine bestehende Obenvachungsansicht zu verSndern kann der Anwender ein Ko- 
pie erstellen und diese danach bearbeiten. 

5.1.6.2.3 Oberwachungsansicht Idschen 

Eine von einem Benutzer erstellte ObenA^achungsanslcht wird geldscht. 

5.1 .6.2.4 Uberwachungsansicht editieren 

Belm Editieren einer ObenA^achungsansicht kann der Anwender durch den Konfigurati- 
ons-Wizard blattem und Einstellungen verandem. 



5.1.6.3 Funktionsgruppe Parameteranzeige 

Die Funktionsgruppe Parameteranzeige visualisiert beliebige Parameter von einem oder 
mehreren Reglern. Aus einer Parameterliste kann der Anwender in Abhangigkeit vom Reg- 
lertyp die zur Verfugung stehenden Parameter auswahlen und online in einer Tabelle dar- 
stellen. In Aniehnung an Baudis und Baudls pro kdnnen Parametergruppen zusammenge- 
stellt werden. Jede Parametergruppe besteht aus einer oder mehreren Parameterseiten. 
Jede Parameterliste kann mehrere Parameter von beliebigen Reglern enthalten. Der An- 
wender kann neue Parametergruppen erstellen und vorhandene kopieren und Idschen. Jede 
Parametergruppe kann jederzeit verandert werden. Die Anderungen werden jedoch erst 
nach dem Speichern der Parametergruppe wirksam. Folgende Aktionen sollen moglich sein: . 
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5.1 .6.3.1 Parametergmppe auswahlen 

Der Anwender wahit eine Parametergmppe aus elner Liste aus. Auf der Oberflache er- 
scheinen die in der Parametergruppe enthaltenen Parameterseiten in Form von Kartel- 
reitern zur Auswahl. 

5.1.6.3.2 Parameterseite auswaiilen 

Durch KHcken auf die Karteireiter wahIt der Anwender die gewunschte Parameterseite 
aus. 

5.1.6.3.3 Parameter-Aktualisierung starten 

Durch Start der Parameter-Aktualisierung werden alle Parianneter auf der angezeigten 
Parameterseite zyklisch aktualisiert. 

5.1.6.3.4 Parameter-Aktualisierung stoppen 
Beendet die zyklische Parameter-Aktualisierung. 

5.1.6.3.5 Antrieb auswSliIen 

Um einen Parameter anzuzeigen muss zunachst eine Antrieb ausgewahit werden. 
Durch die Auswahl des Antriebs ist gleichzeitig der Reglertyp bekannt. In „Parameter 
auswahlen" aus Kapitel 5.1.6.3.6 wird nur die Parameterliste des entsprechenden 
Reglertyps angezeigt. _ 

5.1 .6^3.6 Parameter auswahlen 

Um einen Parameter auf einer Parameterseite anzuzeigen, muss der Anwender die 
Parameternummer des gewunschten Parameters wahlen. Dies geschieht mit einem 
Parameterfenster, das verschiedenen Auwahimechanismen bietet. 

5.1 .6.3.7 Index auswahlen 

Der Anwender wahIt den Index des Parameters aus. 

5.1.6.3.8 Parameter schreiben 

Der Anwender beschrelbt einen Parameter. 

5.1.6.3.9 Parameter-Attribut anzelgen 

Das Attribut des Parameters wIrd In einem klelnen Fenster aufgeschlQsselt angezeigt 

5.1 .6.3.1 0 Parametergruppe erstellen 

Der Anwender kann eine Parametergruppe neu erstellen. Mit Hilfe eines Konflgurati- 
ons-Wizard werden die notwendigen Infomnatlonen vom Benutzer abgef ragt 

5.1 .6.3.1 1 Parametergruppe kopieren 

Um eine Parametergruppe zu verandem kann sle zunSchst kopiert werden und dann 
editiert werden. 

5.1 .6.3.12 Parametergruppe loschen 
Loscht eine Parametergruppe 

5. 1 .6.3. 1 3 Parametergruppe speichern 
Speichert eine veranderte Parametergruppe. 

5.1 .6.3.1 4 Einen Parameter visualisieren 

Mit Hilfe dieser Funktion wird der gewunschte Parameter dem Visuallsierungsmodul u- 
bergeben und graphisch dargestellt. Fur die Konfiguration des Grafik kann eine Stan- 
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dardkonflguration gewahit werden, Oder mit Hilfe eines Konfigurations-Wizards eine 
benutzerdefinlerte Grafik erstellt werden. 



5.1.6.4 Funktionsgruppe Aufzeichnung 

In der Funktionsgruppe Aufzeichnung kann der Werteverlauf von einer Anzahl von beliebigen 
Parametem auf beliebigen Reglem aufgezeichnet werden. . ^ u o 

EIne Aufzeichnung fordert von einem Oder mehreren Antrieben einen oder mehrere Para- 
meter an und legt sie zusammen mit einem Zeitstempel in einer Datenbank ab. Konfiguner- 
bar sind zusStzlich das Zeitintervall mit dem die Parameter von den Antrieben gelesen wer- 
den die Dauer der Aufzeichnung, ein Name und eine Beschreibung der Aufzeichnung. 
Eine Aufzeichnung kann manuell Oder beim Eintreten einer Triggerbedingung gestartet und/ 

Oder beendet werden. .. . i u «i 

Es gibt verschledene Typen von Aufzeichnungen: Aufzeichnungen, die im Ringspelcher des 
G-Drives abgelegt werden und somit nur verfQgbar sind sofern der Resler ein G-Dnve ist. 
(Ringspeicheraufzeichnung) Weiter gibt es Aufzeichnungen, die auf dem BAUDIS IVIET Ser- 
ver abgeiegt werden. (Baudisaufzeichnung) Bei Baudisaufzeichnungen unterscheidet man 
zwel Typen: Typ 1 speichert alie Daten dauerhaft, Typ 2 speichert jeweils nur die Daten ei- 
nes vordefinierten Zeltabschnltts. (z.B. die Daten eines Tages) .... u 
Bekle Typen von Aufzeichnungen sollen aus der Sicht des Anwenders aquivalent zu bedie- 
nen sein. Lediglich bei der Konfiguration der Aufzeichnung muss entschleden werden, ob es 

sich urn eine Ringspeicheraufzeichnung oder urn eine Baudisaufzeichnung handelt 

Die Konfiguration einer Aufzeichnung soil Qber Konfigurations-Wizards erfolgen. 
Folgende Aktionen mQssen mdglich sein: 

5.1.6.4.1 Aufzeichnungskonfiguration erstelien 

Mit Hilfe eines Konfigurations-Wizard soil der Anwender eine Konfiguration einer Auf- 
zeichnung (Aufzeichnungskonfiguration) erstelien konnen. Nach Abschluss der Konfi- 
guration wlrd die Aufzeichnungskonfiguration gespeichert und steht zum Start zur ver- 
fOgung. 

5.1.6.4.2 Aufzeichnungskonfiguration editieren 

Der Benutzer wahit eine existierende Aufzeichnungskonfiguration und verflndert .des- 
sen Eigenschaften. 

5.1.6.4.3 Aufzeichnungskonfiguration kopieren 

Der Benutzer wfihlt eine Aufzeichnungskonfiguration und erstellt eine Kopie. 

5.1.6.4.4 Aufzeichnungskonfiguration loschen 

Der Benutzer ioscht eine Aufzeichnungskonfiguration. 

5.1 .6.4.5 Exportieren einer Aufzeichnung 

Nach erfoigter Aufzeichnung kann eine Aufzeichnung in Fomn einer Datei auf dem 
Cllentrechner exportlert werden. 

5.1.6.4.6 Aufzeichnung stoppen und venwerfen 

Bei der Fehlersuche kann zB. eine Aufzeichnung gestartet werden. urn ein eventueii 
. auftretendes Ereignis aufzuzeichnen. Falls dieses Ereignis wahrend der Aufzeich- 
nungszeit nicht eingetreten ist, kann die Aufzeichnung gestoppt und gleichzeitig ver- 
worfen werden. Dadurch kann das auf dem Server abgespelcherte Datenvolumen re- 
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duziert werden, denn einmal gestoppte Aufzeichnungen werden meist nachtraglich 
nicht mehr geloscht 



5.1 .6,5 Funktlonsgruppe Antriebe sichem (nur G-Drive) 

Die Funktlonsgruppe Antriebe sichem ermoglicht die komplette Sicherung eines G-Dnves. 
Hierbei wird die Firmware zusammen mit dem Parameterdatensatz von der Rashkarte in 
einer Datenbank auf dem BAUDIS NET Server gesichert. Alle Aktionen werden in einem 
Logflle protokolllert. Folgende Aktionen mOssen moglich sein: 

5.1.6.5.1 Sichemng erstellen 

Der Benutzer kann aus einer Liste von Antrieben auswafilen. welohe Antriebe In die Si- 
cherung mIt einbezogen werden sollen. In der Liste sind nur Antriebe gezeigt. fur die 
die Sicherungsfunktlon verfQgbar ist. (z.Zt nur G-Drive) 2u der Antriebsauswahl kann 
noch ein Kommentar hlnzugefiigt werden. Zus§tzlich werden der Benutzer, der die Si- 
cherung erstellt, und ein Zeltstempel erfasst. 

5.1.6.5.2 Sichemng starten 

Das SIchern der Rmiware und der DatensStze fOr die ausgewahlten Antriebe wIrd ge- ^ 
starlet Alle Aktionen werden In eInem Log-Rle protokolliert. _ 

5.1.6.5.3 Sicherung zurQckladen 

EIne bestehende Sicherung wird auf die Antriebe zurOckgespelchert. 



5.1.6.5.4 Sicherung auswahlen 

Vor der Aktion „Slchenjng zurQckspelchem" muss der Anwender eine Sicherung aus 
einer Liste mit auf dem BAUDIS NET Sen/er abgelegten Slcherungen auswahlen. 



5.1.6.6 Funktlonsgruppe Vlsualisierung 

Die Funktlonsgruppe Vlsualisierung ermoglicht die graphische Darstellung belieblger Airf- 
zelchnungen oder Parameter. Der Anwender soil sich verschiedene Darstelkingen mit Hllfe 
eines VIsualislerungs-Wlzanis frel konfigurieren konnen. Folgende Fahlgkelten soil das VI- 
sualisierungsmodul besitzen: ji 
. Verschiedene Diagrammtypen (xy-chart, 3D-Chart, Balkendiagramm, Tortendla- 
gramm, SPC-Chart. Bitleistendarstellung) 
Verschiedene Interpolatlonsarten 
Mehrere Graphen in einem Diagramm anzeigen 
Mehrere Skeden mit verschiedenen EInhelten 

Automatlsohe oder manuelle Auswahl des angezelgten Bereiches (Skalierung) 
Zoom 

Belleblge Beschriftungen der Graphen und Achsen 
Anzelge eines Gitters (Grid) 
Anzeige von Hilfsllnlen 

Frele Farbwahl fOr die einzelnen Diagrammelemente 
Gewlchtung der Daten mit Wlchtungsfaktoren 

Datencursor zur Anzeige des exakten Wertes an einer Stelle des Graphen - 
Folgende /Mctlonen sollen moglich seln: 
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5.1.6.6.1 Aufzeichnung visualisieren 

Der Anwender erstellt mit Hilfe eines Konfiguratlons-Wizards eine graphische Darstel- 
lung fOr ausgewShlte Daten aus einer Aufzeichnung. 

5.1 .6.6.2 Diagramm konfigurieren 

Der Anwender §ndert die Bnstellungen eines bereits existlerenden Dlagramms. 

5.1 .6.6.3 Diagramm exportieren 

Der Benutzer exporUert ein ersteiites Diagramm in einem ausgewShlten Grafikformat. 

5.1 .6.6.4 Diagramm drucken 

Der Benutzer druckl ein ersteiites Diagramm auf dem Drucker. 
5.1.Q.6.5 Diagramm spelchem 

Der Benutzer speichert die Aufzeichnung zusammen mit den Bgenschaften des Dla- 
gramms ab. 



5.1.7 Spezlfizierte Funktionalltfiten fQr dle^enutzergruppe „lnbetrlebnehmer/ 

Entwidkier" - T . . - *• 

Nachfolgend werden die Funktionaiit§ten spezifiziert. die fQr Benutzergmppe Jnbetneb- 
nehmer/ Entwickler" vorgesehen sind. Die Abbildung 5-4 zeigt die Bedienfunktionen, die fur 
die Benutzergruppe Jnbetriebnehmer/ Entwickler vorgesehen sind. 
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Funktionsgruppe Antrieb sichern 

Die Funktionsgruppe Antrieb sicliem ist bereits in Kapitei 5.1 .6.5 beschneben. Zusatzlicin zu 
den dort genannten FunkBonen kann der Inbetriebnehmer eine Sicherung auf dem BAUDIS 
NET-Server Idsclien. 

5. 1 .7. 1 . 1 Sicherung ISschen 

Der Benutzer ISsciit eine auf dem BAUDIS NET Server existierende Sicherung. 



5.1.7.2 Funktionsgruppe Softwareupdate 

Die Funktionsgruppe Softwareupdate emnogliclnt das Instaiiieren Oder Aktualisieren der 
Reglerfirmware des G-Drives. Alle durcligefQhrten Aktionen in dieser Funktionsgruppe wer- 
den in einem Logfiie erf asst. Voraussetzung fQr.die Instaliation oder Aktualisierung der Rmrv 
ware Ist, dass die ausgewalilten Regler eine eindeutlge Regierkennung besHzen. Folgende 
Aktionen mOssen mdglich sein: 

5.1.7.2.1 Antriebe auswahlen 

Der Benutzer waiilt die zu aktualisierenden Antriebe aus eine Antriebsliste aus. 

5.1.7.2.2 Firmware auswahlen ^. 

Der Benutzer wahit die Firmware, die auf die zu aktualisierenden Antriebe geladen -"t 
werden soil aus. 

5.1 .7.2.3 Durchfuhren des Softwareupdates 

Nach der Anzeige eines Wamhinweises wird das Softwareupdate durchgefQhrt. 



5.1.7.3 Funktionsgruppe Datensatzvenwaltung 

Die Funktionsgruppe Datensatzvenwaltung ermSglicht das Laden und Lesen eInes vollstan- 
digen Parameterdatensatzes auf bzw. von eine(r) Auswahl von Reglern. Alle durchgefQhrten 
Aktionen In dieser Furiktlonsgruppe werden In einem Logfiie erfasst. Folgende Aktionen sol- 
len mdglich sein: 

5.1 .7.3.1 Auswahl der Antriebe 

Der Benutzer wShlt die betreffenden Antriebe aus einer Antriebsliste aus. 

5.1.7.3.2 Auswahl des Datensatzes 

Der Benutzer wShlt den Datensatz aus, der auf die Antriebsauswahl geladen werden 
soli. 

5.1 .7.3.3 Durchfuhren des Datensatz-Downloads 

Der Benutzer ladt den ausgewahlten Datensatz auf die Antriebsauswahl. 

5.1.7.3.4 Durchfuhren des Datensatz-Uploads 

Der Benutzer ISdt einen bestehenden Datensatz von einem Regler. 
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5.1.7.4 Funktionsgruppe Events konfigurieren (nur G-Drive) 

Die Funktionsgruppe ^Events konfigurieren" bietet die Moglichkeit beliebige Ereignlsse in der 
Ereignisanzelge und Im Logbuch aufzuzeichnen. Der im Kommunikations-PC des G-Dnves 
vorhandene Event-Broker wird mit Hilfe der unter genannten Funktionen konfigunert, so dass 
er die gewunschten Parameterkombinationen auf das Elntreten des korrfigunerten Ereignis- 
ses Qberwacht. Beim Eintreten des Ereignlsses wird es an den BAUDIS NET Server ge- 
schlckt und dort In der Ereignisanzeige angezeigt. Folgende Aktionen sollen moglich sein: 

5.1.7.4.1 Aritriebe auswfihien 

Der Benutzer wShlt die Antrieb aus, fOr die ein Event konfigurlert oder geloscht werden 
soil. 

5.1.7.4.2 Event konfigurieren 

Der Benutzer konfigurlert ein Ereignis mIt Hilfe eines Konfigurations-Wizards 

5.1.7.4.3 Event loschen 

Der Benutzer loscht einen Event aus eine Uste mit laufenden Events. StandardmaBig 
vorhandene Events, wie z.B. Fehler kOnnen nicht gel6scht werden. 

5.1 .7.4.4 Eventkonflguratlon zum Antrieb schicken 

Der Benutzer schlckt den konfigurierten Event zu einer Antriebsauswahl und aktlviert 

. " ihn. " " ' . ■ . :. 

5.1.7.5 Funktionsgruppe Skripte 

Die Funktionsgruppe ..Skripte" bietet die I\/I6gilchkeit komplexe DiagnosefunWjonen durch- 
zufQhren. Urn komplexe Abfragen von Parametem zu realisleren konnen PERL-Sknpte ge- 
schrieben wenden. die auf den entsprechenden Kommunlkations-PC geschiclct werden und 
dort ausgefOhn werden. Folgende Akttonen sollen mdgllch sein: 

5.1.7.5.1 Laden des Skripts auf den Sender 

Der Benutzer ISdt das Skript von dem Kommunlkatlons-PC eines Antrlebs auf den Ser- 
ver. 

5.1.7.5.2 Laden des Skripts zum Antrieb 

Der Benutzer ladt ein aus eIner LIste ausgewahltes Skript auf einen ausgewahlten An- 
trieb. 

5.1.7.5.3 Skript editleren 

Der Benutzer editiert ein Skript. 

5.1 .7.5.4 Ausfuhren des Skripts auf dem Kommunlkations-PC 
Der Benutzer startet das Skript auf einem Antrieb. 
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i,2 Beciliieini®lb©rfli©lhi© z.m Ainilaig©inil]c©BTifigyiral!o©oD 

FQr die Konflguration und Einrichtung des BAUDIS NET Application-Servers soli eine spe- 
zielle Bedienoberflache zur VerfOgung gestellt werden, die auf die Benutzung von geschul- 
tem Personal zugeschnitten ist. Sie enthSIt komplexe Funktionalitaten. die die Konfiguration 
einer groBen Aniage mit zahlreichen Antriebssystemen wesentlicli schneller und einfaclier 
als bisher ermdgllcht. FQr das Arbeiten mit dieser Benutzeroberflache ist keine Verbindung 
"zum Application Server notwendig. so dass die Konfigurationsarbeiten vom Inbetriebnahme- 
personal auch offline durchgefOhrt werden konnen. Die offline erzeugten Daten konnen dann 
nach Abschluss der Arbeiten via ftp auf den Applteatlon Server geladen werden, sofem eIne 
Kommunikationsverblndung existiert 



5.2.1 Zielgruppe 

Geschultes Personal, das mit der Inbetriebnahme einer Aniagen betraut ist. 

5.2.2 . PeDiirspraclliiigkeilt 

Die Benutzeroberflache zur Anlagenkonflgu ration soli in einer deutsc^ien und engllschen 
Version zur VerfOgung stehen. 



5:2.3 lirtplementrerunig ~ '.^ . 

Nachdem die Benutzeroberflache zur InbetrlebnahmeunterstQtzung nur einem begrenzten 
Benutzerkreis zur VerfOgung gestellt werden soil und sie komplexe Funktionen beinhalten 
soli, ist eine Implementierung als Java-OberflSche sinnvoll. Hierdurch wird es Im Unterschled 
zur webbaslerten Oberflache auch m5glich bestlmmte Arbeiten durchzufOhren, ohne dass 
eine Verbindung zum Application Sen/er besteht. 

5.2.4 SpezSfizEeiree Fuimlic&lioinalloltateini 

Die nachfolgend spezifizierten Funktionen sind In FunkBonsgruppen und Funktionen grup- 
plert. 

5.2.4.1 FunktlonsgruppeDatensatzerstellung 

In der Funktionsgruppe Datensatzerstellung kann der Anwender fOr eine bestlmmte Soft- 
wareversion einen Parameterdatensatz erstellen urid editieren. Der Parameterdatensatz 
setzt sich aus einer Reihe von Modulen zusammen, die aus der Standarddatenbank ent- 
nommen werden kdnnen. Folgende Aktionen mOssen mSglioh sein; 

o Auswahl der Standard-Parameterdatenbank auf der Festplatte des Anwenders 
o Auswahl des Reglers fOr den der Parameterdatensatz erstellt werden soli 
o Auswihlen der Module aus der Standarddatenbank durch Drag and Drop aus ei- 
nem Drivebrowser, der den Inhalt der Standarddatenbank darstellt. 
o Editieren der frel anderbaren Parameter, Ansloht der nicht anderbaren Parameter 
o Speichem des Parameterdatensatzes in einer temporaren Datenbank. Hierbei soli 
der Datensatz in einem fur die Sen/erkomponente „AnIagenkonfiguration" geeig- 
neten Format abgelegt werden. 
o Obertragen des erstellen Datensatzes auf den Appllcation-Sen/er 

5.2.4.2 Funktionsgruppe Anlagenkonfiguration 

Die Funktionsgruppe Anlagenkonfiguration ermoglicht das Zusammenstellen einer Aniage 
aus verschledenen Komponenten und deren graphische Reprfisentation in einem Anlagen- 
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bild. Das erstellte Aniagenbild wird, zusammen mit der zugehorigen Datenbank nach Ab- 
schluss der Arbeiten via ftp auf den BAUDIS NET Application Sender geladen. 
Folgende Aktlonen mOssen mogllch sein: 

• Laden der Komponentendatenbank von der Festplatte des Anwenders 

• Auswaiil und Konfiguratlon der Komponente 

• Platzieren der Komponente auf einem Aniagenbiid 

. Speichern der Aniagenkonfiguratlon In einer temporSren Datenbank auf der Fest- 
platte des Anwenders 

• Hintergrundbild laden und loschen 

• Obertragen der temporaren Datenbank in die Datenbank der Serverkomponente 
Aniagenkonfiguratlon" 

• Laden der Aniagenkonfiguratlon aus der BAUDIS NET Datenbank in eine tempo- 
rSre Datenbank auf der Festplatte des Anwenders. (z.B. fur die DurchfQhrung von 
Anderungen) 
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6 Spezifikation des Application-Servers 

Das vorliegende Kapitel gibt einen Oberblick Qber die Architektur des Applicsation Servers 
von BAUDIS NET. Nach einem SystemQberblick In Kapitel 6.1 wird vereucht, die Vielzahl der 
benotlgten Funktlonen in Komponenten zu gruppieren. Im Kapitel 6.2 wird der Funktionsum- 
fang dieser Komponenten eriautert. « » ,. « 

Das Kapitel 6.3 beinhaltet den objektorientierten Entwurf des BAUDIS NET Application Ser- 
vers. Hier wird es sich je nach Ergebnis der objektorientierten Modellierung zeigen, ob die in 
Kapitel 6.2 gebildeten Komponenten den Komponenten der Implementierung entsprechen. 



6.1 Systemiiberblicic 

Aufbauend auf Abbildung 4-1 zeigt die.folgende Abblldung eine detallllertere Slruktur 
BAUDIS NET. 




von 



• 









Antrlebsebene 
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BAUDIS NET 
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Abbildung 6-1 : Detaillierte Struktur von BAUDIS NET 

Im wesentlichen besteW BAUDIS NET aus drel Ebenen: 

BAUDIS NET Bedienoberfiachen: , , ^ . ^ 

Alle Funktionalitaten von BAUDIS NET kSnnen Ober die bereits in Kapitel 5 spezifizierten 
Bedienoberflachen bedlent werden. FQr den Benutzer von BAUDIS NET soil es kelnen Un- 
terschied machen. ob er sich im lokalen Netz an der Aniage befindet oder Qber das Internet 
Oder eine Telef on-Einwahlverblndung mit dem Application-Server verbunden ist 

BAUDIS NET Application Server ^ ^ . / 

Der BAUDIS NET Application Server stellt den Kern der gesamten Anwendung dar. Seme 
Funktionalitat ist in verschiedene Komponenten unterteilt. Jede Komponente ist in sich abge- 
schlossen und stellt seine Funktionalitat der webbasierten BedlenoberflSche oder anderen 
Serverkomponenten zur VerfQgung. Alie fQr die Funktion der Komponente notwendigen Da- 
ten werden in der angeschlossenen Datenbank gespeichert. Um die Kapselung und Konsis- 
tenz dieser Daten zu gewahrleisten kann auf diese DatenbestSnde nur Ober die von der Ser- 
verkomponente zur VerfQgung gestellten Funktlonen zugegriffen werden. Dadurch wird auch 



SpezifikationBaudisNET24 



Selte 34 von 41 



Spezlf ikation des Appli< 




Servers 



3? 



Ver. 1.0 



sichergestellt, dass eine Anderung an der .Datenbankstruktur ei'ner Serverkomponente nicht 
unbedingt Anderungen an anderen Serverkomponenten nach slch zieht. 
Um die Funktionalitaten der Serverkomponenten den Bedienoberflachen zur Verfugung zu 
stellen soli eine geeignete Infrastruktur geschaffen werden. Fur die Kommunikation mit der 
Weboberflache zur Inbetriebnahme, Oberwachung und Diagnose soli ein Apache Webserver 
eingesetzt werden. Dieser stellt HTML-Selten zur Verfugung, In die Java-Applets Oder Flash- 
Module eingebettet sind. Die auf der Oberflache anzuzeigenden Oaten werden mIt Hilfe von 
Soap (Simple Object Application-Protokoll) zu den entsprechenden Modulen ubertragen. Die 
Benutzeroberflache ruft z.B. eine Funktion der Serverkomponente G-Drive auf. Die zu uber- 
gebenden Parameter und die Bezeichnung des Funktion wird mit Hilfe des Soap Protokolls 
auf das Intra- oder Internet geschickt, Um die Transparenz gangiger Firewalls zu gewahr- 
leisten, wird der Funktionsaufruf in Form eines HTTP-Telegramms verschickt Ein Webserver 
auf der Seite des Application Servers empfangt die HTTP-Telegramme mit eirle Soap^lnhalt 
und leitet sie an den Soap-Server welter. Der Soap-Server decodiert die Anf rage und ruft die 
gewunschte Funktion aus der Servekomponente G-Drive auf. Die Funktion wird ausgefuhrt 
und die Ruckgabewerte wiederum in das Soap Protokoll umgesetzt und als HTTP- 
Telegramm an die Oberflache geschickt. 

Eine wesentliche Eigenschaft eines Diagnose- und Oberwachungssystems ist, dass der Be- . 
nutzer uber an der Aniage auftretende Ereignisse zeitnah informlert wird. Dies stellt fur die 
oben gezeigte Architektur eine Schwierigkeit dar, da sowohl fur die Kommunikation uber So- ^ 
ap als auch fur die HTML-Selten eine erelgnisbasierte Benachrichtlgung nicht vorgesehen i 
ist. Als Abhilfe mussen an der Aniage auftretende Ereignisse, wie z.B. das Auftreten eines 
Fehlers Oder das Update eines Parameterwertes in einer Oberflache, Qber einen Event~^ 
Kanal den BenLftzeroberffacheh mitgeteilt werden. Nachdem diese Verblndung uber TCP/IP 
lauft Ist fOr die Verblndung Qber das Intemet ein offener Port am Rrewall notwendig. 

Antriebsebene: 

Die Antriebsebene stellt dem Application Server die Daten von den Reglern zur Verfugung. 
In Abbildung 6-1 sind nur G-Drives mit daran angeschlossenen Kommunikations-PC darge- 
stellt, es sollen Jedoch zukQnftig auch andere Regiertypen wie z.B. Regler aus der b-maXX 
Familie unterstQtzt werden konnen. 
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6.2 Die Serverkomponenten 

Wie bereits in Kapitel 6.1 beschrieben besteht der Application Server aus verscliledenen 
gekapselten Serverkomponenten die ihre Funktionalitaten der Benutzeroberflache zur Verfu- 
gung stellen. Durch die komponentenbasierte Struktur soil sichergestellt werden, dass der 
Funktionsumfang von BAUDIS NET erweitert werden kann. Die Serverkomponenten slnd als 
Java-Module realisiert. 




Abbildung 6-2: Verschiedene Serverkomponenten 

Die Abbildung 6-2 zeigt die verschiedenen Serverkomponenten von BAUDIS NET. Die fol- 
genden Kapitel spezifizleren die einzelnen Serverkomponenten: 



6.2.1 Serverkomponente BAUDIS NET 

• Die Serverkomponente BAUDIS NET enthalt die fur den Betrieb von BAUDIS NET notwen- 
dlgen FunkHonalltaten. Es enthSIt eine Reihe von Funktionen die Im folgenderi kun: erklSrt 
werden: 

Benutzerverwaltung 

Alle Funktlonalitaten in BAUDIS NET sind gegen unautorisierten Zugriff geschutzt Jeder 
Benutzer hat eine Benutzerkennung und gehorl zu einer Benutzergruppe, die ihm ein Recli- 
teprofll fOr den Zugriff auf die Funktlonalitaten der Serverkomponenten emnoglicht DIese 
Information werden in der Benutzerverwaltung konfiguriert und abgespelohert. Jede Funktion 
In den Serverkomponenten hat eine eindeutlge Kennung. Will ein Benutzer auf eine Funktion 
zugreifen, wird zunachst an der Sen^erkomponente Benutzervenwaltung nachgefragt ob der 
Benutzer die entsprechenden Reohte fur das AusfQhren dieser Funktion besitzt. Die Daten- 
bank In der die Benutzerdaten abgelegt werden soil durch Verschlusselung vor unberechtig- 
tem Zugriff gesohOtzt werden. Folgenden Funktionen sollen zur VerfQgung gestellt werden: 

• Benutzer einriohten 

• Benutzer Idschen 

• Reohte des Benutzers editieren 

• Autorlsierung prufen (intern) 
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Sprachenauswahl . . « ... 

BAUDIS NET soli mehrere Sprachen unterstotzen. Die Auswahl der Sprache geschieht vor 
dem Anmelden an der Benutzeroberflache. FQr die Bedienoberfiaclne zur Anlagenkonfigura- 
tidn ist nur ein eingeschranlcter Sprachumfang vorgeselien (z.B. Deutsch und Englisch). 
Fehlertexte und andere iVleldungen werden in der entspreclienden Spraclie an die Oberfla- 
clie ubertragen. FQr die Weboberflactie werden fQr jede zu unterstOtzende Sprache entspre- 
chende HTML-Selten zur VerfOgung gestellt 

Log-Nachrictnten . „ . • i i-i 

Alle VorgSnge die von einer Benutzeroberflache beauftragt werden, sollen in einem Log-File 
aufgezeichnet werden sein. Hierbei wird jedem Vorgang eine eindeutlge Kennung zugeord- 
net. Bei Aufruf wird ein entsprechender EIntrag In die Log-Datenbank erzeugt. Bei erfolgrei- 
chem Abschluss wird dieser Eintrag abgeschlossen. u / .■ 

Wesentliche VorgSnge auf den Kommunikations-PCs und anderen Reglern konnen ebenfalls 
In eine daf Qr vorgesehene Datenbank geschrieben werden. Sle sollen mit derselben eindeu- 
tlgen Kennung versehen werden.. so dass eine alle Aktionen durchgangig einander zugeord- 
net werden konnen. Folgenden Funktionen sollen zur Verfugung gestellt werden: 

o Konfigurieren des Loggings 
o Einstellen der Detalltiefe 

o Komprimleren und SIchem der Log-pat?!?ba"k 

ESnstellumgem . ^ ^ ^, * , 

Weltere, fur den Betrleb und die Konfiguration des Application Servers notwendige Einstel- 
lungen sollen hier zentrai vorgenommen werden kSnnen. 



@.2.2 Seorveirkompoinieinite Amllageinikonlflguirafloini 

Die Serverkomponente Aniagenkonfiguration enthait alle notwendigen Daten Qber die. Konfi- 
guration der Aniage. Diese belnhaltet Daten Qber die in der Aniage vorhandenen Kompo- 
nenten, Gmpplerung der Komponenten, Adressen etc. Es sollen Funktlonalltaten zur VerfO- 
gung gestellt werden, die die Darstellung der Aniagenkonfiguration In Fomi verschiedener 

»5berslchtsbilder eriauben. (Siehe dazu auch Kapitel 5.1.5.5) Weiterhin sollen alle Doku- 
mentatlonen zu den in der Aniage enthaltenen Daten zur VerfOgung gestellt werden. 
Belm Entwurf der Serverkomponente Aniagenkonfiguration ist darauf zu achten, dass mit 
Hilfe der Funktlonalltaten dieser Komponente bellebige Anlagen im Bereich der Antriebs- 
technik beschrleben werden konnen. 



6.2.3 Serverkomponeiraite @°Oirlve 

Die Sen/erkomponente G-Drive enth§lt alle G-Drlve speziflschen Funktionalitaten. HIerzu 
gehSren das Lesen und Schrelben von Parametem, die Bedienung des Ringspeichers sowie 
Funktionen f Or das Softwareupdate und den Up-/Download von Parameterdatensatzen. 



6.2.4 Serverkomponente Diagnose 

Die Serverkomponente Diagnose beinhaltet die Diagnose-Funktionalitaten von BAUDIS 

NET. Hierzu gehdrt die Aufzeichnung von Erelgnissen (z.B. Fehlem) sowie die Aufzetehnung - - • - 

von belieblgen Daten. Die zu erfassenden Ereignlsse sollen konfigunerbar sein und unab- 

hangig davon ob sie von einer Oberfiache angefordert werden In Fomi von Logbuchem in 

der Datenbank abgelegt werden. 
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Urn die Allgemeingultigkeit der Komponente Diagnose zu erhalten, sollen hier keine regler- 
spezifischen Funktionaiitaten enthalten sein. Fur reglerspezifische Funktionalitaten wie z.B. 
das Lesen und Schreiben voir Parametern soil auf die entsprecliende Serverkomponente 
zugegriffen werden. 



6.2.5 Serverkomponente b-maXX 

Die Serverkomponente b-nnaXX entfialt alle b-maXX spezifischen Funktionalitaten. Eine 
weitergehende Spezifikation dieser Serverkomponente findet in einem separaten Dokument 
statt und ist nicht Bestandteil des vorfiegenden Entwicklungsprojekts. 
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6.3 Objektorientierter Entwurf des Application Servers 

Das vorliegende Kapitel dokumentiert den objektorientierten Entwurf des Application Ser- 
vers. Fur das Verstandnis dieses Kapitels sind Kenntnisse in UML (Unified IVIodeling Langu- 
age) erforderlich. Nachdem sich der objektorientierte Entwurf noch In einern f rQhen Stadium 
befindet, werden die naclifolgenden Abbildungen nur mit wenig Kommentar versehen und 
standig ergSnzt. AuBerdem sind sie den in Kapitel 6.2 spezifizierten Komponenten noch nicfit 
zugeordnet. 

Alle im Application Server vorliandenen Klassen konnen in zwei Ebenen elngeteilt werden: 
Ebenel : Modeli-Logik 

Auf der Modell-Logik-Ebene werden die Objekte aus der Realitat (z.B. Maschine, Gerate) 
sowie nicht physikalisch vorhandene Objekte (z.B. Aufzeiciinungen, Ereignisse) modelliert. 
Zusammen ergeben sie eine Modell fur die Inbetriebnahme, Diagnose und Uberwachung 
eines Antriebssystems. 

Naclifolgend werden einlge Objekte aus der Modell-Logik-Ebene In Klassendiagrammen 
spezifiziert. 
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Abbildung 6-3: UML-Klassehdiagramm fur eine Aniage 

Die Abbildung 6-3 zeigt ein Klassendiagrannm fur ein Antriebssystem mit einer Vielzahl von 
Antrieben. Eine Aniage kann Maschinen beinhalten, Maschinen konnen Sektionen belnhal- 
ten, Sektionen konnen Antriebsgruppen beinhalten. Antriebsgruppen (z.B. Dmckeinheiten) 
beinhalten Aggregate. Ein Aggregat enthSIt verschledene Gerate. Ein Aggregat besteht aus 
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einem oder zwei Geber, einem Leistungsteil, einem Motor und einem Regler. Vom Regler 
gibt es verschiedene Typen. Er kann eine Firmware und einen Datensatz enthalten. 
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Abblldung 6-4: UML-Klassendlagramm f Qr eIne Aufzelchnung 

Die Abbildung 6-4 zelgt ein Wassendlagramm fOr eine Aufzeichnung. Teil einer Aufzeichnung 
1st eine Aufzeichnungsl<onfiguration sowie Aufzeichnungsdaten, sofern die Aufzeiclnnung 
bereits einmal gestartet wurde. Die Klasse Aufzeichnungskonfiguration ist abstrakt. Von ilir 
eiben zwei Klassen: Die Klasse Ringspeiciier-Konfiguration sowie die Klasse Baudis Auf- 
zeichnungs-Konfiguiation. Einem Objelct vom Typ Baudis Aufzeichnungs-Konflguration kann 
mit einem Ereignis verknQpft werden, das z.B. eine laufende Aufzeichnung nach dem Auf- 
treten des Ereignisses beendet 
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Abbildung 6-5: UML-Klassendiagramm fQr den Erelgnlsmanager 

Die Abbildung 6-5 zeigt Ausschnltte aus einem Wassendiagramm fOr den Ereignismanager 
in BAUDiS NET. Der Ereignismanager verwaltet alie im Antriebssystem moglichen Ereignis- 
se (z.B. Feliler, Wartungsmeidungen, infos, Warnungen...) Wird ein Ereignis von einer belie- 
blgen Komponente an den Ereignismanager gemeWet wIrd es vom Ereignismanager wetter 
verarbeftet. Z.B. I<ann mit einem Ereignis eine Aktion verkniipft werden, wie z.B. die Anzelge 
in der Ereignisanzeige der Bedienoberflache Oder mit deni Verschicken einer e-mail. 



Ebene 2: Darstellungs-Logik 

Auf der zweiten Ebene werden Klassen spezifiziert, welche die auf den Bedienoberfiacrien 
dargestellten Funktionen realisieren. DafOr werden die Klassen der Modeliebene benutzt. 
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1 Systemuberblick 

Der Kommunlkations-PC Obemimmt die Kommunikationsaufgaben zwischen dem Regler 
und der AuBenwelt. In der vorliegenden Spezifikation wird die Softwarestruktur fur die 
Kommunikation zum G-Drive spezifiziert. 

Jedes Gerat, das mit dem G-Drive kommunizieren soil muss ihn Qber eine geeignete Soft- 
ware-Schnittstelle auf dem Kommunikations-PC ansprechen. Mit Hilfe des Kommunikati- 
ons-PCs kann beinaiie jede Software-Schnittstelle, die auf Ethernet basiert, realisiert wer- 
den. 

Das folgende Kapitel gibt einen Oberblick Qber die Softwarearcliitektur auf dem Kommuni- 
kations-PC. EIne Einordnung in das Gesamtkonzept von BAUDIS NET ist der Spezifikation 
von BAUDIS NET. Kapitel 4 zu entnehmen. Die Abbildung 1-1 zelgt die Softwarestruktur 
auf dem Kommunikations-PG. 



^ G-Drlve 




1 Ethernet, TCPAP od. VDPAP 



Abbildung 1-1: Softwarestruktur auf dem Kommunikations-PC 

Jede Funktionalitat, die vom G-Drive der AuBenwelt zur Verfugung gestellt werden soli, Ist 
In einem Softwaremodul (Request-Broker) realisiert. Z.B. stellt der Request-Broker „Para- 
meter" eine Parameterschnittstelle zur Verfugung Qber die bellebige Parameter des G- 
Drives gelesen und geschrieben werden konnen. Der Request-Broker „Fehler und Events" 
stellt bellebige Erelgnlsse und Fehler nach auBen dar. Die beiden Request-Broker „Para- 
meter-Bedarfsdaten" und ,^yklische Sollwerte" erledigen die Kommunikation mit der Steu- 
erung. Sle sind nur auf den Reglem vorlianden die den Master im Sercos-Ring bllden und 
somit mit der Steuerung kommunizieren mOssen. Der Request-Broker „Soflware- 
Download" stellt Funktionen fQr einen automatischen Download der Regler-Rrmware be- 
reit. 

FQr jede an einem Request-Broker eingehende Anfrage wird ein eigener Prozess erzeugt, 
der die Anfrage bearbeitet. So wird siciiergestellt, dass eIn Request-Broker viele Anfragen 
gleichzeitig bedienen kann. 

Im wesentlichen kommuniziert der Kommunikations-PC des G-Drive mit der Steuerung 
und dem BAUDIS NET Application Server. Hierbel muss sichergestellt werden, dass die 
Naclirichten von und zur Steuerung in jedem Fall ohne unnotigen Zeitverzug am G-Drive 
verarbeitet werden, da sie fQr den Betrieb der Aniage von wesentlicher Bedeutung sind. 
Nachdem die Anfragen auf dem G-Drive nur sequentiell verarbeitet werden konnen, muss 
die Moglichkeit bestelien, Anfragen von der Steuerung vorrangig zu bearbeiten. Dies soli 
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durch Vergabe von Prioritaten fur die Anfragen sichergestellt werden. Jede Anfrage an die 
den Connection-Manager, der die Sclinittstelle zum G-Drive venwaltet, 1st mit einer von 5 
Priorltatsstufen versehen. Anfragen mit der hochsten Priorltat werden vom Connection- 
Manager vor alien weiteren ansteiienden Anfragen an den G-Drlve geschickt. Anfragen mit 
niedriger Prioritat werden Immer nacii alien anderen anstelienden Auftragen behandelt. 
Hierdurcli l<ann sichergestellt werden, dass ein Auftrag mit hSchster Prioritat -z.B. von der 
Steuerung- in jedem Fall als nacliste Anfrage auf dem G-Drive bearbeltet wird. 

Neben den Request-Brolcem gibt es weitere optionaie Softwaremodule auf dem Kommunl- 
kations-PC: Ein Logging-Sen/er empf§ngt Log- und Debugnachrichten von den Request- 
Brokem und stellt sie der AuBenwelt zur VerfQgung. Ein Webserver bietet eine einfaciie 
Weboberfiache zur Bedlenung und Konflguration. Ein FTP-Server und eine Client zur Zelt- 
synchronisation sind weitere Komponenten auf dem Kommunikatlons-PC. Mit einem Perl- 
interpreter konnen beliebige Skripte mit Diagnose- oder Steuerungsfunktionalltaten aus- 
gefOhrt werden. 
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2 Spezifikation des Request-Brokers „Parameter" 

Das Kapltel 2 spezKlzlert die Funktionalitaten des Request-Brokers „ParamGter» und die 
dazugehSrigen Kommunikatlons-Protokolle. 

2.1 Spezifizierte Funktionalitaten 

Folgende Funktionen sollen Im Request-Broker .Parameter" verfQgbar sein: 

Lesen von Parametern ,^ ' x r> r^ - 

Der Request-Broker Parameter soli eine Gruppe von beliebigen Parametern von G-Dnve 
lesen konnen. HIerbei soil neben dem einmaligen Lesen ein zyklisches Lesen von Para- 
metern mogllch sein. Das Intervall zwischen den LesevorgSngen und die Anzalil der Lese- 
vorgSnge sollen vom Client einstellbar sein. „ . « 

Urn die Kommunlkation mit dem G-Drive zu verringern soli der Request-Broker „Parame- 
tei« alle bereits geiesenen Parameterinformationen (z.B. Attrlbut, Name, Einhelt) in einem 
Cache ablegen, so dass sie beim emeuter Anforderung des Parameters nicht emeut vom 
Regler gelesen werden mQssen. Dynamische Parameter, die ihre Eigenschaften zur Lauf- 
zeit verandem konnen sollen nicht in den Cache aufgenommen werden. Sle mQssen jedes 
Mai vollstSndig gelesen werden. 

Schrelben von Parametern „ . s r> 

Der Request-Broker Parameter soil eine Gruppe von beljebigen Parametern auf :d§n G- 
Drive schrelben konnen. HIerzu mQssen die zu schreibenden Parameter In das benotigte 
Fomiat gewandelt werden, was vorab ein Lesen der Parameterlnfonmatlonen erfordert, 
sofem sie nicht Im Cache verfQgbar sind. 

2.2 Funklionsweise . ^ ^ 

Abblldung 2-1 gibt einen Oberbltek Qber den groben Ablaut beim Verarbeiten einer Anfrage 
Im Request-Broker „Parameter". 
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Abbildung 2-1: Flussdiagramm Request-Broker ..Parameter" 

Nach der Initialisierung des Brokers wird ein Socket (Ustensocket) an einem konfigurierba- 
ren Port geoffnet und auf eine Verbindungsanfrage eines Clients gewartet. Verblndet sich 
ein Ciient mit diesem Ustensocket wird eine Kopie des Brokerprozesses erzeugt, die die 
Anf rage des Clients bearbeitet. Der ursprQngiiciie Prozess (Vaterprozess) wartet weiterh n 
an seinem Ustensocket auf sicli verbindende Ciients. So ist siciiergesteiit. dass sich vieie 
Clients gleichzeitig vom Broker bearbeitet werden konnen. 

Nach der ProzeBabspaitung scliiieBt der Vaterprozess sein Verblndungssocket und der 
Kindprozess sein Ustensocket. Danach 1st der Kindprozess bereit zum empfangen der 
Anfrage vom Client. Bel Eintreffen der Anfrage wird diese vom Socket gelesen und deco- 
diert. Je nach Typ der Anfrage wird diese entsprechend ausgefuhrt. , , .» 

Nach Verarbeitung der Anfrage vom Ciient wartet der Kindprozess eine bestimmte Zeit- 
spanne auf neue Anfragen vorn Client. Trifft innerhalb der vordefinierten Zeit keine neue 
Anfrage vom Client ein oder tritt wahrend der Bearbeitung des Anfrage ein Fehler auf. wird 
die Verbindung beendet. 



2.3 Schnittstellen-Spezifikation Request-Broker ..Parame- 
ter"- Client 

Imfolgenden Kapitel wird die Kommunikations-Schnittstelle zwischen dem Request-Broker 
..Parameter" und dem Client spezif iziert. Es soil hier ein einfaches und schnelles propneta- 
Ires Protokoll zum Einsatz kommen. . 
In den folgenden AbschnWen werden die benotigten Teiegramme spezif iziert-Jeder ernp- 
fangene Protokollstring wird beim Decodieren soweit mogiich auf GQitigkeit der entha te- 
nen Daten QberprOft. Bei Auftreten eines Fehlers wird dieser in einer speziellen Fehler/ 
Bestatigungsnachricht an den Client zurQckgeschickt. Nach erfolgreicher Bearbeitung der 
Anfrage wird eine Bestatigungsnachricht an den Ciient versendet. 
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Die Verbindung zwischen Server und dem Request-Broker kann durch SchlieBen des So- 
ckets von beiden Seiten jederzelt beendet werden. . „ u 
Alle Daten werden als String ubertragen. Das hat den Vorteil. dass das Protokoll auch von 
„primitiven" Clients (z.B. Skripte) oder sogar ..von Hand" benutzt werden kann. Zwischen 
den Bementen des Telegranr^ms befinden sich Trennzelchen. Am Telegrammanfang und 
am Telegrammende stehen jeweils versclniedene Kennungen. 

Client Request-Broker: Dateh anfordern: 

Die nachfolgende Tabeile 2-1 spezifizlert die Anfrage des Clients an den Request-Broker 
..Parameter" zur Obermittiung von Daten. (Die grau hinteriegten Bereiche des Telegramms 
sind In alien Telegrammen vorhanden). 



Datum 


Stringlange 


^ Sm If-I #1 Ir A t4 


Beschreibunci 


















mmmm. 
















Plioritat 


. . -IcB. 


0<X'<=10 


PTioritat mit der die Anfrage behandelt werden soli • 
GOItlgkelt max-^prio . 


Polllngstatus 


k.B. 


0<X<b3 


Qibt an, wie oft die Daten gesendet werden: 
1 : Obertragung gem^ Polling Anzahl 
2: Obertragung unbegrenzt 
GOItlakeit max_po!ling. status 


Polling Anzahl 


k.B. 


X>=0 


Gibt an, wie oft die DatensStze maximal gelesen und gesendet 
werden (nur aOltia bei Polllngstatus 1> 


Polling Inten^all 


WJB. 




Zeltlntenrall nach dem die Daten emeut gelesen und gesendet 
werden: 

0: so schneH wie mdgllch 
(X): Inten/all In MHIIsekunden 


Anzahl P-IDs 


k.B. 


0 < x >s 20 


GOltlpkelt max_Dld anzahl 


P-ID Nr. 1 


k.B. 


x>0 




P-Index Nr.1 


k.B. 


x>=0 


Parameter-Index zum Parameter Nr.1 


P-ID Nr. 2 


k.B. 


x>0 


Parameter-ID des zwelten geforderten Parameters 


- P-lndex Nr. 2 


k.B. 


x>=0 


Parameter-Index zum Parameter Nr. 2 * 


P-ID Nr. 3 


k.B. 


x>0 


Parameter-ID des dritten geforderten Parameters 


P-lndexNr.3 


k.B. 


x>»0 


Parameter-index zum Parameter Nr. 3 










P-ID Nr. X 


k.B. 


x>0 


Parameter-ID des x-ten geforderten Parameters 


P-lndex Nr. x 


k.B. 


x>=0 


Parameter-Index zum Parameter Nr. x 











Tabeile 2-1: Kommunlkatlonsprotokoll zum Losen von Daten 



Client -> Request-Broker: Daten sciirdben _. „ . « , 

Die nachfolgende Tabeile 2-2 ieigt die AUffordemng des Clients an den Request-Broker 
Daten zu schreiben. 
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uaiuiTi 




Gfiltlakeit 


Beschrelbung 


■fr *: •'** ' BEOT'*.' • ' '^•'^ 


'Siehd oben' ** 

^^Iwi WW 


' Siehe; oben' 








:j' '. ■;■ 'v^v;f^f[vy ! 






,v-t«:-»::^'*'.*^''*>*.r"-* - 5"*'- ■/ 








. ir?7.'.' -/sv". ^ • 




\ 2: parani^er schreiben (fm^f^ daraesUIItll^^^k^:^^'' 


Priorltat 






Prioritat m!t der die Anfrage behandelt werden soil 


. AruBhl P-IDs . 


Siehe oben 


Siehe oben 


Anzahl der getorderten Parameter 


P-ID fslr 1 


Siehe obGn 


Siehe oben 


Parameter-ID des ersten gefbrderten Parameters 


P-lndAxNIr 1 


Siehe oben 


Slehe oben 


Parameter-Index zum Parameter Nr. 1 


r til CU I IC7lC7l WOI I 


k.B. 


Stringl 


Wert des zu schreibenden Parameters 


p.in Mr O 


Sieha oben 


Slehe oben 


Parameter-ID des ersten getorderten Parameters 


p.lnHay Mr 2 


Siehe olsen 


Siehe oben 


Parameter-Index zum Parameter Nr. 2 




k.B. 


String! 


Wert des zu schreibenden Parameters 


p.in Mr Q 


Slehe oben 


Slehe oben 


Parameter-ID des ersten getorderten Parameters 




Siehe oben 


Siehe oben 


Parameter-Index zum Parameter Nr. 3 


Parameterwert 


k.B. 


String! 


Wert des zu schreibenden Parameters 










P-ID Nr. X 


Siehe oben 


Slehe oben ' ' 


' Pararrretei^D des ersten getorderten Parameters 


P-lndexNr.x 


Siehe oben 


Slehe oben 


Parameter-Index zum Parameter Nr. x 


Parameterwert 


30 Zeichen 


Stringl 


Wert des zu schreibenden Parameters 











TabeBle 2°2: fiCommunikationsprotokoll zum Schreiben von Oaten 



Request-Broker Client: Fehiermeldung senden: 

Nach Empfang eines Telgramms durch den Broker wird bei Auftreten eines Fehlers eine 
Fehlermeldung an den Client yerschickt. In Fehler steht die Fehlenneldung. die zum Ab- 
bruch des Brokerprozesses gefQIirt liat. 



Datum 


StringlSnge 


GQItigkeit 


Beschreibung 












^:jiVSiehe\6bep 


?(;;.§!eheGben;;r;f;i; 






:SiiSrehe'^bbenT'j:^ 


>n'Slehe! oben'^^' 






b SleheJobeh':j^':f; 


•«.Sleheiob8nts:?.:i 


*Glbt,dlejiftt;detMes^g^a!ife\;^ 
-:^-3rFdifenneidutttfjtTi^^^^ 


Fehler-Nr. 


k.B. 


X>0 


EIndeutlge Fehlemummer 


Fehlerstring 


300 Zeichen 




Beschreibung des Fehlers 


f/:;.?:;^^.EOT : ' /Iv-^ 






I Ende^ja^rariruTO;;;?^ 



Tabelie 2-3: Fehlenmeldung 
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Request-Broker Client: Parameter schrelben-Bestatlgung: - . 

Nach dem Schreiben von Parametem durch den Broker wird eine Bestatigung an Client 
verschickt. 



Datum 


Stringlange 


GQItigkeit 


Beschrelbung 






: Siehejoben 


Beglnn^desTelegranp?..^^ ^^'v-.M^'^^^M^^^A^M^^^^^: 




VvSIehe^joben J \r;.. 


^ :Slehe:'obea-;f ; 


v^imflC^esS 




}'^'SleKe.oben.,;:;?jr* 


y; Slehe^pben.-j^v 


•■;^itzuaerda^T^ 




^r.. SlQhe.;6ben: : 


».vsiehesoben.<^l;v 


i^i^\Parameter:scbreiben^^^^^ 
l^^iFSilerTTJe^ 


Anzahl PIDs 


Slehe oben 


Siehe oben 


Anzahl der PID- Nummem 


P-ID Nr. 1 


Siehe oben 


Slehe oben 


Parameter-ID des ersten geschriebenen Parameters 


, P-lndexNr. 1 


. Slehe oben 


Siehe oben 


Parameter-Index zum Parameter Nr. 1 


FehlerNrI 


k.B. 


X>=0 


Falls der Parameter nicht geschrieben werden konnte: Feh- 
lemr. vom G-Drlve (0 fflr erfolarelch) 










P-ID Nr. 2 


Slehe oben 


Siehe oben 


Parameter-ID des zwelten geschriebenen Parameters 




















Tabeile 2-4: Bestillgungs-Nachrlcht fOr das Schreiben von Parametern 



Request-Broker Client Daten senden: 

Fur die (zyklische) Ubertragung der Daten vom Broker zum Server wird das Telegramm 
aus Tabeile 2-5 verwendet. 



Datum 


Stringlange 


GQItigkeit 


Beschrelbung 




v;SieheJp&ervr>/fe«^ 


iftSlehebberi;;:;"; 






v^'Sieji^iobphi'-^i?:'; 


;:;;Si8[lT!eobe)j^f^; 






f;;§!eha?Sbei£v^^^^^ 


t"' Slehe:'oben >v^, 


.vzelt^u^i^d^lej^^^ 




^» 




.sQabtdle;^^^^^^ 

V ^.2i;Para!Tieter§cl^rfe|ib^^^^ 
;;:^^{:e!?leriTieidLi^ 
-i::Parametgtsc^^ 
; ^" Parame^^^^^^^ 


AntwortTyp 


Slehe oben 


Siehe oben 


1: kurze Antwort (nur PID-Nr. P-lndex und Wert, und Fehler 
gOltig) 

2: lanqe Antwort {qesamter Datensatz) 


Anzahl P-IDs 


Slehe oben 


Slehe oben 


Anzahl der geforderten Parameter (Glbt es eine Obergrenze x 
•?) ' • • • ^- 


P-ID Nr. 1 


Siehe oben 


Slehe oben 


Parameter-ID des ersten geforderten Parameters 


P-lndex Nr. 1 


Siehe oben 


Siehe oben 


Parameter-Index zum Parameter Nr. 1 


P-Wert Nr. 1 


Siehe oben 


Siehe.oben 


Wert von P-ID Nr. 1 


Fehler 


Slehe oben 


Slehe oben 


Falls der Parameter nichtgelesen werden konnte 


P-Name Nr. 1 


80 Zeichen 




Name und Beschrelbung des Parameters 


P-AttrlbutNr.l 


Bitmaske 
Unsigned Int 




Attrfl3ut-Wort: DatentSnge. Datentyp. Anzeigefonnat etc. 



SpeziflkatlonKommunlkationsPG10_Soflware 



Seite 10 von 20 



Request-Broker Parametei 



Ver. 1.0 



PMnfoNr.l 


BItmaske 
Unslaned Int 




Info-Wort Schreibschutz, Spelcher-Modus 


P-Einheit Nr. 1 


20 Zefchen 




EInheit des Parameters 


Maxwert Nr. 1 


30 Zeichen 




Maximaiwert des gelesenen Parameters 


Minwert Nr. 1 


30 Zeichen 




Minimatwert des gelesenen Parameters 










P-ID Nr. 2 






Parameter-ID des zweiten geforderten Parameters 










P-ID Nr. 3 






Parameter-ID des drttten geforderten Parameters 










. P-ID Nr. X 






Parameter-ID des x-ten geforderten Parameters 










P-ID Nr. X 






Parameter-ID des ersten geforderten Parameters 











Tabelle 2-5: Kommunikadonsprotokoll zum Senden von Daten 



2.4 Schnittstellen-Spezifilcation Request-Brolcer „Parame- 
ter" - G-Drlve 

FQr die Kommunikatlon des Request Brokers Parameter mit dem G-Drive soli das BAS- 
COM-Protokoll eingesetzt werden. Das BASCOM-Protokoll 1st kompatlbel zum PECOM- 
Protokoll. Es erweltert das PECOM-Protokoll um file-transfer Funktionalitaten. 

Eine weitergehende Spezif ikation des BASCOM-Protokolls findet Im Dokument pSpezifika- 
tion.des BASCOM-Protokolls" statt. 
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3 Spezifikation des Request-Brokers „Fehler und E- 
vents" 

Das Kapitel 3 spezifiziert die Funktionalitaten des Request-Brokers „Fehler und Events" und 
die dazugehdrigen Kommunikations-Protokolle. 

3.1 Spezif izierte Funktionalitaten 

Der Request-Broker „Fehler und Events" soil am G-Drive auttretende Fehiler oder andere 
konfigurierbare Ereignisse der AuRenwelt zur VerfQgung stellen. Uber die unten spezifizlerte 
Telegramme soil es m6gllch sein, beiiebige Parameter zu Qbenwacheii und belm Elntreten 
eines Ereignisses eine Nachricht an den Client zu verschicken. 

Ein Unterschied zum Request-Broker „Parameter" ist, dass zum Client keine permanente 
Socket-Verbindung besteht. Nach der Konfiguration des Events wird diese abgebaut und erst 
beim Auftreten des konfigurierten Events wieder aufgebaut. HierfQr muss auf der Seite des 
Clients ein entsprechender Server-Port zur VerfQgung steiien. 

Nachfolgend werden die MSglichkeiten zur Konfiguration von Events spezifiziert: 

Abonnleren einer Event-Benachrlchtlgung: _ 

M\t Hllfe des Request-Brokers „Fehler und Events" soli die Ubenwachung von bis zifilO Pa- 
rametem auf das Auftreten-eines-derfolgenden Ereignisse emiSgllcht werden: • . ;• 

• Parametemvert Ist grofier ais Vergleichswert 

• Parametenwert ist kleiner ais Vergleiciiswert 

• Parametenwert ist gieicli dem Vergleichswert 

• Parametemvert Ist unglelch dem Vergleichswert 

• Parametenwert weicht vom Vergleichswert weniger ais xx Promille ab 

• Parametenwert weicht vom Vergleichswert mehr oder genau xx Promille ab 

• Parametenwert hat sich gegenuber dem Wert zum Konflguratlonszeltpunkt geSn- 
dert 

Die 10 Paare aus zu iibenwachendem Parameter und dem Vergleichswert sind untereinan- 
der entweder mit ..ODER" Oder mit „UND" verknupft. . ^ • 

Die Abtastzeit mit der die Bedlngung QberprOft werden soil, soli ebenfalls konfigunerbar sein. 
Bel Auftreten eines Events werden die aktuelien Parametenwerte an den Client geschickl, 
damit dieser bei ODER-verknOpften Events den ausiosenden Parameter feststellen kann. 

KQndigen eIner Event-Benachrichtigung: 

Ein abonnierter Event lauft solange bis er gekundlgt wird. MA Hilfe der J<undigungs- 
Nachricht" kann eine Event Abonnement wieder aufgelost werden. 

3.2 Funktionsweise 

Wird noch welter spezifiziert.... 



' Dies ist besonders fQr float-Werte wichtig, da Rundungsfehier durch Konvertiemngen entstehen k6n- 



nen 
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3.3 Schnittstellen-Speztfikation Request-Broker „Fehler 
und Events" - Client 

Client Request-Broker: Events abonnieren: 

Die nachfolgende Tabelle 2-1 spezifiziert das eventbasierte Senden von Parametern. 



Datum 


StringlSnge 


Gultigkeit 


Beschreibung 








Beginn desTetegrarruns,/-' ^ '• V/-ydr.W;^5vV*a^iV'^ 








/.Kennung des Sen/ers/ Brokers (fOr Ij6gglrig-Zweck6)^t<'?i^^^^r^i^ 
•StrlnflianaB:«maxi:sen^eAcennunflyength:vr^i^^^ 


VV.^'ZeltstOTli^I'M<;i 






Zelt zU'.def dasTelegrararn abgesc^ 
•Sirinaiano&lmaigielfetem 




L-*, < i\eine/Degren^.«i.-t 




:3P;:Eventabpnnlerenvg^vS4;vt-.^^^^ 
^ablHSk^t?«rfiS^^ 


Priorit&t 


k.B. 


t)<X<s10 


PrioritSt mit der die Anfrage behandelt werden sdi 
GQItiakeit max_jDrlo 


VerknOpfung 


k.B. 


1 <sx<=2 


1 : ODER-VerknQpfung zwischen den Parametern 
2: UND-VerknOpfung zwischen den Parametern 


Polling Interval! 


k.B. 


X>=0 


Zeitlntervaii in dem die Daten vom Regler gepollt werden: IT 
0: so sclinel) wie mdglich 
(x): Interval! in Militsekunden 


. Anzahl P-IDs 


- - .k.B.. 


4)<x>=l20 


Anzahi- der zuQberwachenden Parameter- • - • - • 

GOItlgkelt rnax_pid_anzahl 


P.in Mr -i 
r'lU INT. 1 


K.D. 


X > 0 


Parameter-ID des ersten zu vergieiclienden Parameters 


D.lnrlav Kir i 


K.O. 


X>sO 


Parameter-index zum Parameter Nr.1 


cveni* 1 yp 
Nr. 1 






1 : Parameterwert ist grd3er als Vergleichswert 

2: ParametenA/ert ist kieiner als Vergleicliswert 

3: Parametenvert ist gleicli dem Vergleichswert 

4: Parametenvert ist unglelch dem Vergleichswert 

5: Parameterwert wefcht vom Vergleichswert weniger als xx Promilie 

ab 

6: Parameterwert welcht vom Vergleichswert mehr oder genau xx 
Promilie ab 

7: Parameterwert liat sich gegenOber dem Wert zum Konfigurations- 
zeitpunkt geSndert 


1 oieranz iNr. i 






Abwelchung in Promilie nach oben oder unten 


vergieicnswen i>ir. 
1 


ou ulcnen 




vergieicnswert mit dem der aKtueiie Wert vergllcnen Wird 










P-ID Nr. n 


k.B. 


X>0 


Parameter-iD des ersten geforderten PaiBmeters 


P-lndex Nr.n 


k.B. 


x>=0 


Parameter-Index zum Parameter Nr. n 


Event-Typ 
Nr.n 


k.B. 


0<x>s3 


1 : Parameterwert ist grdBer als Vergleichswert 

2: ParametenA/ert ist kieiner ais Vergleichswert 

3: Parametenvert 1st glelch dem Vergleichswert 

4: Parameterwert ist ungleich dem Vergleichswert 

5: ParametenA/ert welcht vom Vergleichswert weniger als xx Promilie 

ab 

6: Parameterwert welcht vom Vergleichswert mehr oder genau xx 
Promilie ab 

7: ParametenA/art hat sich gegenOber dem Wert zum Konfiguratlons- 
zeltpunkt geSndert 


Toleranz Nr. n 






Abwelchung in Promilie nach oben oder unten 


Vergletehswert Nr. 
n 






Vergleichswert mit dem der aktuelle Wert vergllchen wird 




-A'-; 




Bld^desj^i^gramgis/;/^^^^ 



Tabelle 3-1: Kommunlkationsprotokoli zum eventbasierten Lesen von Daten 
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Die nachfolgende Tabelle 2-1 spezifiziert das Telegramm fur das Kundigen der Ereignisbe- 
nachrlchtigung. 



Datum 


Stringlange 


Gaitfgkett 


Beschreibung 














ZekSiehii. 


•Kerinungides^Serye^^ 
:stfirit5lfiriae::ma)(ti^ 


'.^oV-ZeifetempeliyifV 






:;Zeit-zu"^derxla^^Xele^ 
iStfirtfitefiSfeSfrS^ 








:Glbtd!a^ut:aeriMesisagCah:Sf^» 











Tabelle 3-2: Kommunikationsprotokoll zum Kundigen der Ereignisbenachrichtigung 



Die nachfolgende Tabelle 3-3 spezifiziert das Telegramm zur Benachrichtigung naoh dem 
Eintreten des konfigurierteri Event 



Datum 


Stringlange 


Guitigkeit . 


_ Beschreibung.^ 




mmmmm 












^StriRflranaBl?.roa;&SefVerlcenri{jnoM^^^ 








JZ^lzCdetida^^e 

?sMl£^^ 










Anzahl P-IDs 


tcB. 


0 < X >= 20 


Anzahl der zu Oberwachenden Parameter 
GOltigkelt max pld anzahl 


P-ID Nr. 1 


leB. 


x>0 


Parameter-ID des ersten zu vergteichenden Parameters 


P-lndexNr.1 


k.B. 


X>s=0 


Parameter-Index zum Parameter Nr.l 


P-WertNr.1 






Parameter-Wert zu PID Nr. 1 beim Eintreten des Events 










P-ID Nr. n 


k.B. 


X>0 


Parameter-ID des ersten geforderten Parameters 


P-lndex Nr. n 


k.B.. 


X>sO 


Parameter-Index zum Parameter Nr. n 


P-Wert Nr. n 






Parameter-Wert zu PID Nr. n belm Eintreten des Events 











Tabelle 3-3: Telegramm zur Benachrichtigung bei EIntreffen des konfigurierten Erelg- 
nlsses 



SpezifikatlonKommunikationsPC10_Software 



Seite 14 von 20 



Request-Broker Fehler^Wf Events Ver. 1 .0 

3.4 Schnittstellen-Spezifikation Request-Broker „Fehler 
und Events" - Request-Broker „Parameter' 



Der Request-Broker „Fehler und Events" verwendet fCir die Kommunikation mit dem Regler 
das in einem gesonderten Dokument spezifizierte BASCOM-Protokoll. 
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4 Spezifikation des Request-Brokers „Parameter- 
Bedarfsdaten" 

4.1 Spezifizierte FunktionalitSten 



4.3 Schnittstelie Request-Broker Parameter-Bedarfsdaten - 



Noch za spezifizieren. 



4.4 Schnittstelie Request-Broker Parameter-Bedarfsdaten - 
G-Drive 

Der Request-Brol<er ..Fehler und Events" verwendet fQr die Kommuniltatlon mit dem Regler 
das in einem gesonderten Dolcument spezifizierte BASCOM-Protol<oll. 



Noch zu spezifizieren. 



4.2 Funktionsweise 



Noch zu spezifizieren. 



Client 
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Request-Broker ParameWpedarfsdaten v,>J Ver. 1 .0 

5 Spezifikation des Request-Brokers „Zyklische 
Sollwerte'' 

5.1 Spezlfizierte Funktionalitaten 

Noch zu spezifizieren. 

5.2 Funktionsweise 

Noch zu spezifizieren. 



5.3 Schnittstelie Request-Broker Zyklische Sollwerte 
Client 

Noch zu spezifizieren. 



5.4 Schnittstelie Request-Broker Zyklische Sollwerte - G- 
Drive 

Der Request-Broker „Fehler und Events" verwendet fur die Kommunlkatlon mit dem Regler 
das In einem gesonderten Dokument spezifizierte BASCOM-Protokoll. 
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6 Spezifikation des Request Brokers „Software- 
download" 

6.1 Spezifizierte Funktionajitaten 

Der Request-Broker „lnstall/ Setup" soll das Laden der Firmware auf die Regjerhardware, 
sowie das Sichem der Firmware von der Reglerhardware ermdglichen. 



6.2 Funktionsweise 

Noch zu spezifizieren. . 



6.3 Schnittstelle Request-Broker Softwaredownload - 
Client 

Noch zu spezifizieren. 



6.4 Schnittstelle Request-Broker Softwaredownload - G- 
Drive 

Der Request-Brol<er „Fehler und Events" venwendet fur die Kommuriiltation mit dem Regler 
das in einem gesonderten Dolcument spezifizierte BASCOi\4-Protoi(oll. 
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7 Spezifikation des Connection-Managers 

7.1 Spezifizierte Funktionalitaten 

Noch 2u speziflzieren, 

7.2 Funktionsweise 

Noch zu spezifizieren. 
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8 Weitere Dienste auf dem Kommunilcations-PC 
8.1 Spezifikation des Logging Servers 

8.1-1.1 Funktionsweise 

Alle Meldungen, die in den Request-Broker-Prozessen erzeugt werden, warden fonnatiert 
und an die Konsole, In ein Logfiie oder eine Nachriclitenwarteschiange des Log-Servers ge- 
schrieben. Von diesem Log-Server konnen die Nachrichten dann zu bellebigen Servern / 
Rechner verschickt werden. 

Um die spatere automatische Auswertung der Logfiles zu ermdgliciien, werden yerschiedene 
Nacliriclitentypen definiert, die die Interpretation der Naclirioliten erieichtern. (z.B. Debug, 
Daten, Error ...) 

Werteres wird spater spezif iziert. 



8.2 Spezifikation der Skriptunterstutzung 

Funktionsweise 

M\t Hilfe der Skriptunterstutzung auf dem Kommunlkations-PC sol! eine flexible und frei proJi^lX 
grammierbare Sclinittstellen geschaffen werden, mit der auch zukQnftige Anforderungen an ' 
Uberwachung und Diagnose abgedeckt werden sollen. Mit Hilfe eines Perl-Interpreters k6n- 
nen bellebige Skripte auf dem Kommunikations-PC ablaufen, die auf die Funktionalltaten der 
Request-Broker ^Parameter** und „Fehler und Events" zugreifen. So konnen komplexere 0- 
berwachungsfunktionen lokal auf dem Kommunikations-PC ausgefuhrt werden ohne das 
eine Beiastung des Netzwerks durcli Ubertragung von Daten stattfindet. Die Skripte werden 
mit Hilfe des ftp-Servers auf dem Kommunikations-PC ubertragen oder sind dort schon ais 
Tell der Software vorhanden. 

Fur den Start und die Datenubertragung zur der das Skript aufrufenden Instanz ist folgendes 
Protokoll vorgesehen: 

Start des Skripts: 

Fehlermeldung: 

Ergebnisdaten: 



8.3 Zeitsynchronisation, FTP-Server, Telnet 

Fur die Synchronisierung der Systemzeiten sollen alle Kommunikations-PCs ilire Systemzeit 
regelmSBig Qber einen auf dem BAUDIS Server lauf enden Zeitserver synchronisieren. 
Der FTP-Server und der Telnet-Zugang dienen fOr das Software-Update des Kommunikati- 
ons-PCs und zur Wartung. 
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Vielachsenanwendungen mit jsynchronisiert^ Vernetzung und 
asynchroner Kopplung an die Leitebene 

Ing.(grad) Harold Meis, Dipi.-Ing. Thomas Ikchaftary 
BaumiiUer Anlagen-Systemtechnik GMBH & CO., Numberg, 



Kurzfassung 

Durch die Nutzung der Einzelantriebstechnik ist die Aiueahl der synchron zu betreibenden Axitriebe stetig ge- 
wachsen. Gleichzeitig erfordert die Notwendigjceit einer effiziente Diagnose einen hohen Datendurchsatz durch 
alle Ebenen der Automatisienmgspyramide. Bin Zusaininenwirken der beiden Koxmnuoikatioiistedinologien 
SERBAS und Etiiemet ennoglicht die Realisierung der Forderung nach hoher Synchronitat und einer asyndiro- 
nen £kOpplung an die Steuerungs- und Leitebene. Durch entsprechende Strukturen konnen so bis zu 10416 An- 
triebe synchron betrieben werden, wobei die Sollwertvorgabe asynchron von der Leitebene erfolgt 
Zur Cberwachung dieser groBen Zahl von Antrieben smd neue Diagnosekonzepte und Strukturen unabdingbar. 
Mit BAUDIS NET gibt es einen neuen Ldsungsansatz. 



1 VerhetzteAntriebe-Vielachs- 
anwendungen 

Der seit einigen Jahren ungebrochene Trend mecha- 
nisch gekoppelte Bewegungsablaufe m Fertigungsma- 
schinen diurch einzehi angetriebene Aggregate zu CC' 
setzen, fuhrt zu einer standig steigenden Zahl von syn- 
chronisiert zu betreibenden Antrieben- Die in der 
Vergangenheit ubliche mechanische Leitachse (K5- 
nigswelle) wird dabei dorch eine virtuelle Leitachse 
ersetzt. 

1,1 Anforderungen an die Einzelan-* 
triebstechnik 

Die Bewegungsablaufe, die es mit der Einzelantriebs- 
technik nachzubilden gilt, reichen dabei von direkt^ 
Leit- Folgebetrieb bis zu komplexen Kurvenyerlaufen, 
die von einer realen Leitachse abgeleitet werden miis- 
sen. Die Anforderungen an die dynamische und stati- 
sche Oenauigkeit smd dabei betrachtlich. Es gilt die 
mechanischen Steifigkeiten der mechanisdien Leit- 
achse zu erreichen bzw. zu uberbieten. 
Doch nicht nur die regelungstechnischen Anforderun- 
gen sind fiir der Erfolg solcher Systeme relevant, auch 
Synchronitat und die Konfigurierbarkeit der einzehi 
angetrieben Aggregate ist fur den Einsatz an Produk- 
tionsmaschinen entscheidend. Die Anzahl der syn- 
chronisiert zu betreibenden Antriebe kann dabei 
durchaus mehrere hundert betragen. Typische Bei- 
spiele sind in der Druck- \md Textilmaschinenbrache 
zufinden. 

Diese groBe Zahl an Antrieben erfordert natuigemaB 
ein hohes MaB an Zuverlassigjceit. Aoch darf der Aus- 



feil eines einizelnen Antriebs oder einer Gnqjpe von^fe 
Antrieben nicht zum Aus&ll des Gesamtsystems fuh-* 
ren. 

Kommt es dennoch zu Storungen, dann ist ein System 
zur schnellen und sicheren Fehleranalyse imd Beseiti- 
gung unerlasslich. Zur Vermeidung von Storungen 
sind Methoden zur Vorbeugenden Wartung" eiforder- 
lich. Weiter mussen Diagnose und ServicemaBnahmen 
von jedem Ort der Welt aus durchfuhrbar sein. 
Zusammenfassend sind zwei Anforderungen ^kenn- . 
bar, die entscheidenden Einfluss auf die Kommunika- \ 
tionsstruktur einer Vielachsanwendung haben: Einer- 
seits muss eine synchronisierte Kommunikation zwi- 
schen den Antriebsreglem erfolgen, andrar^seits ist 
eine asynchrone Kommunikation mit der Steuerungs- 
und Leitebene erforderlich. 




Bild 1 Automatisierungspyramide einer Vielach- 
sanwendung 

Bild 1 zeigt die Automatisierungspyramide einer Viel- 
achsanwendung. Die Antriebskoinponenten in der 



0 



Feldebene werden von den Steuerungskon^onenten 
der Steuerungsebene gesteuert Auf ' d^ darOber lie- 
genden Leitebene werden dem Anlagenbedien^' auf- 
bereitete Daten und Informationen zur Verfugung ge- 
stellt, die zur Bediennng und Oberwachimg der Anla- 
ge verwendet werden. Die Spitze der Pyramide bildet 
die Planungsebene. Aufgrund der oben genannten An- 
forderungen einer Melachsanwendung ist ein hoher 
Datenaustausch zwischen den einzelnen Bbenen der 
Automatisierungspyramide erforderlich. Hieizu komr 
.men in der Baumuller SyncDrive-Technologie zwei 
sich erganzende Kommunikationstechnologien zum 
Binsatz: SBRBAS^ und Ethernet mit TCPyiP und 
UDP/IP. 

2 Synchronisierte Kommuhika- 
tionmitSERBAS 

Um eine Vielzahl von Antrieben (z.B. eine Zeitun^- 
druckmaschine mit bis zu 400 Antrieben) hochgenau 
synchronisiert zu betreiben, sind auf diesen Anwen- 
dungsfall zugeschnittene Losungen unerlasslich. Da- 
her konunt fur die synchronisierte Kommunikation auf 
der Feldebene eine staik an SERCOS-Inter&ce ange* 
Idmte Rommiinikationstedbnologie zum Einsatz. In 
den folgenden Abschnitten wird SERBAS naher er- 
Uutert 

2.1 SERBAS Ringstruktaren 

2.1.1 Der SESBAS Antriebsiing 

Der SERBAS-Antriebsring besteht aus einem Kom- 
munikations-Master mit Leitachsfunktionalitat (MDS) 
und aus bis zu 48 Antriebsreglem (MDC). tJblicher- 
weise wird erne mechanisch funkdonelle Einheit mit 
einem Antriebsring reaiisiert. Der Kommunikations- 
Masfeer halt dabei die Anbindung zur Steurungsebme 
und verteilt die . Sollwerte sowie Steuerinformationen 
an die betroffenen Antriebsregler. Ebenso werden von 
den Antriebsreglem Istwerte und Statusinfomiationen 
fur die Steuerungsebene bereitgestellt Auf diese Art 
ist ein Baustein entstanden, der einiseln in Betrieb ge- 
nommen und getestet werden kanru Bild 2 zdgt einen 
SERBAS-Antriebsring mit einem Kommunikations- 
master und 9 Antriebsreglem. Ihsgesamt beinhaltet 
dies^ Ring 10 geregelte Antriebseinheiten. Die ge- 
strichelten Verbindungen zwischen den Antriebsein- 
heiten stellen die Redundanzfunktion in der SERBAS- 
Kommunikation dar, Sie wird in Kapitel 2.3 erklait 



. SERBAS ist eine hochgenaue synchronisierte se- 
nelle Schnittstelle in ^weiterung yon SBRCOS- 
Ifiter&ce 



2.1.2 Die SERBAS Qaerkommuiukation 

Die Verknupfimg der Antiebsringe geschieht durch 
emen zweiten SERBAS-Ring. Dazu steht im Kommu- 
nikations-Master (MDS) eine zweite SERBAS- 
Schnittstelle zur VerfQigung, Mit dieser wild eine 
Querverbindung zwischen den Kommimikations- 
Mastem hergestellt Auf diese Weise konnen bis zu 32 
Teilnehmer^ dJi. Kommunikationsmaster, in der Quer- 
konmiunikation miteinander verbunden werden. Auf 
dieser Ebene werden die Sollwerte von bis zu 32 Leit- 
achsen mit den zugehorigen Steuer- und Statusinfor- 
mationen zur Verfiigung gestellt Dabei kann jeder 
Antrieb einer beliebigen Leitachse zugeordnet wer- 
den. Es besteht weiterhin die Moglichkeit die Antriebe 
in Gruppen zusammen zu fasseiL Damit wird eine fle- 
xible Anpassung an die geforderten Produktionsbe- 
dingungen mdglich. 

So ist ein neuer Baustein entstanden, der bis zu 32 x 
48 = 1538 Antriebe synchronisiert betreiben kann. 
Bild 3 zeigt die SERBAS-Querkoxmnunikation zu- 
sammen mit den Antriebsringen aus Bild 2. 




Bild 2 Der SERBAS Antriebsring 

2.13 DerMulti-Lliik-Controller 

Um die Kommunikationsstruktur der Maschinen- 
struktur anziq)assen und die Anzahl der miteinander 
synchronisiert kommunizierender Bausteine zu erh5- 
hen, wurde in der Baumuller Sync-Drive Technologie 
ein weiteres Strukturelement eingefubrt: der Multi- 
Link-Controller (MLC). 

Der Multi-Link-Controller wird als einer der 32 mog- 
lichen Teilnehmer in den Queikommunikationsring 
aufgenommen. Das ist zur Zeit bei bis zu 7 Quer- 
koromimikationsringen mdglich. Der MLC verteilt 
dabei die fur den synchronisierten Betrieb aller ange- 
schlossenen Ringe relevanten Daten. Im wesendichen 



sind das alle Leitachsinfonnationen der 32 im Ge* 
samtsystem mdglichen Leitachsen, so dass jeder der 
im System voifaandene Antriebe einer dieser Leitach- 
sen zugeordnet werden kann. Bild 4 zeigt die Kopp- 
limg von bis zu 7 Antriebssektionen mit Hilfe des 
Multi-Link-ControUers. 

Durch den Einsatz des MLC erhobt sich die Anzahi 
der synchronisiert zu betreibraden Antriebe auf 48 x 
31x7 = 10416. Weit wichtiger als diese groBe Zahl 
an Antrieben ist die Mdglichkeit, das Antriebssystem 
und seine Kommimikationsstruktur an die Struktur der 
zu betreibenden Maschine anzupassen und damit auch 
komplexe Antriebssysteme beheirschbar zu machen. 
Einzelne an den MLC gekoppelte Konomuiukations- 
ringe konnen aus dem Gesamtsystem entfemt und 
wieder binzugefiigt werden ohne den restlichen Teil 
der Anlage zu beeinflussen. Bin wichtiger Aspekt ftir 
Inbetriebnahme und Wartung. 



2.2 SoUwertgenerierimg and Vertei- 
lung 

Durch den Einsatz von dezentralen Sollwertgenerato- 
ren ist es nicht erforderlich, zentrale Lagesollwerte zu 
generieren und im System an alle Antriebe synchroni- 
siert zu verteilen. Stattdessen muss cine in der Leit- 
ebene angesiedelte Sollwertquelle aur bei Anderung 
neue Drehzahl- und Beschleunigungssollwerte bereit- 
stellen. Diese Sollwerte werden dann in einem System 
aus strukturierten SERBAS-Ringen an die Antriebe 
verteilt, und, synchronisiert durch den SERBAS-Takt, 
dezentral zu LagesoUwerten umg^echnet. Die Syn- 
chronitat der Antriebsregler ist entscheidend fur das 
eireichbare Ergebnis. Ean Beispiel aus der Applikation 
Zeitungsdruck: Eine zeitliche Verschiebung des Soll- 
werts um l^s fuhrt bei einer Druckgeschwindigkeit 
• von 35.000 Exemplaren/h zai einem Winkelfehler von 
3,5 mGrad. Auf dem P^ier kann das einen Versatz 
von 0.01 mm bewirken. (Umfing der Druckwalze ca. 
1.100 mm) 
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Bild 4 Kopplung von bis za 7 Antriebssektionen mit HUfe des Multi-Link-Controllers 
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2.3 Die Redundanzfunktion in der 
SERBAS-Kommunikation 

Durch die SERBAS-Ringstruktur wurde der Ausfall 
eines Teilnehmers zur Unterbrechung der Kommuni- 
kation und damit zum Ausfall des gesamten betroffe- 
nen Antriebsiings fuhien. Der Fordmmg nach einem 
robusten System wird durch eine redundant ausge- 
fuhrte SERBAS-Struktur entsprochen. Dabei wird ein 
zweiter SERBAS-Ring reaUsiert, bei dem jeweils der 
iibemachste Teilnehmer miteinander verbimden wird 
Durch diese Strufctur wird sichergestellt, dass jeder 
zweite Teilnehmer ausfallen kann, ohne die Kommu- 
nikation der restlichen verbliebenen Teilnehmer zu 
geShrden. Die Redundanzftmktion ist konsequent fur 
alle SERBAS-Ringe reaiisiert Die gestrichelten Ver- 
bindungen in Bild 2 zeigen die redundante SERBAS- 
Ringstruktur. 



Asynchrone Kommunikatioii 
mil Ethernet 



Ginks) zeigt ist es bei Verwendung von Ethernet ein- 
&ch m5glich SoUwerte von mehreren Steuerungen 
(SPS)zuerhalten. 



3.1.1 Zyklische Kommunikatioii 

Zu den zyklischen Daten gehdren Soil- Istwerte sowie 
Steuer- und Statusinfonnationen. Diese werden mit 
UDP/IP ubertragen. Da bei dem hier gehutzten ver- 
bindungslosen Protokoll eine sichere Obertragung 
nicht gewahrleistet ist, werden ausschliefilich Daten 
ubertragen^ deren Verlust den Betrieb der Maschine 
nicht gefahrdet Durch den im Veigleich zu TCP ge- 
ringeren Protokoll-Overhead, konnen kleine Obertra- 
gungszyklen gewahlt werden. Ein Ausfall von 2 UDP- 
Telegrammen kann dann toleriert werden ohne den 
Betrieb der Maschine zu gefahrden. Der Kommunika- 
tions-Master in der Antriebsebene (MDS) stellt somit 
die Schnittstelle zwischen der asynchronen Kommu- 
nikation zur Steuerungsebene und der synchronisierten 
Kommunikation in der Antriebsebene dar. 



Die Verbindung zwischen Feldebene tmd der Steue- 
rungsebene sowie zwischen Feldebene und der Leit- 
ebene in der Automatisierungspyramide aus Bild 1 
wird durch asynchrone Kommxmikation iiber Ethernet 
reaiisiert Es kommen dabei die Protokolle TCP/IP 
und UDP/IP zum Einsatz. Jm folgenden werden die 
verschiedenen Anforderungen an die asynchrone 
Kommunikation erlautert 



3.1 Kommunikation zur Steuerang 

Bei der Kommunikation zwischen Feldebene und 
Steuerungseb^e wild zwischra zyklischen Daten und 
Bedarfsdaten unterschieden. Bild 5 (links) zeigt die 
Kommunikation mit der Steuerungsebene. Wie Bild 5 



3.1.2 Bedarfsdatenkommunikation • 

Das verbindungsorientierte Protokoll TCP wild zur 
Obertragung von Daten zur Konfiguration bzw. zur 
Parametrierung des Antriebsystems eingesetzt Um 
den Preis des erhdhten Overhead (ca. 15 Mai mehr als 
bei SERBAS) kann mit TCP von einer gesichertm 0- 
bertragung ausgegangen werden* 
Auch hier findet die Kommunikation zwischen Steue- 
rungsebene und Kommimikations-Master (MDS) in 
der Antriebsebene statt Die Verteilung der Informati- 
onen in der Antriebsebene erfolgt mit Hilfe des SER- 
BAS-Protokolls. 



DIag nosestat ion 




Bild 5 Asynchrone Kommunikation mit der Steuenmgsebene (SPS) sowie der Leitebene (Diagnose) 
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3.2 Kommunikation fur die Anlagen- 
uberwachung und -Diagnose 

Mit der wachsenden Zahl von Antrieben werden 
Fimktionen zur Inbetriebnahme und Oberwachung der 
Antriebe unenlbehrlich. In der Leitebene werden Stan- 
dig Informationen aus der Antriebsebene benotigt 
Dabei' handelt es sich im wesentlichen um S3^teniin- 
formationen wie Status- und Fehlermeldungen, War- 
tungsinfonnationen sowie Aufseichnimgen zur Quali- 
tatsuberwachung. 

Zur Auswertung der Daten steht in der Leitebene eia 
Diagnoserechner (BAUDIS NET Application Server) ^ 
zur Verfugung. Auch hier wird Ethernet als Koimnu- 
nikationsmedium- .eingesetzt Das OSI-Schiditen* 
modell enndglicht konq>Iexe Konununikadonsmecha- 
nismen zwischen Antrieb- und Leitebene. Da die Di- 
agnose unabhangig von der restlichen BCommunikation 
erfolgen soil, (schliefilich soUen u.a. aiich Konimuni* 
kationsprobleme in den SERBAS-Ringen erkannt 
werden) muss jeder Antriebsregler uber Ethernet er- 
reichbarsein. 



3.2 JL . .Dezentrale Diagnose. ...... 

Um die anfallrade Datenmenge sinnyoll verarbeiten 
zu konnen, ist eine dezentrale Vorverarbeitung erfor- 
derlich. Ebenfalls sinnvoll ist es» umfangreiche Diag- 
nosefunktionen moglicbst nahe am betro£fenen Gerat 
anzusiedeln. Zu diesem Zweck ist in jedem Antriebs- 
regler ein Kommunikations-PC integriert Dieser H- 
bemiiomt neben der Anbindung der Antriebsregler an 
das Ethernet auch die Event-basierte Kommunikation 
zum BAUDIS-Swrer. Bild 6 zeigt die Systranstruktur 
von BAUDIS NET. 
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Blld 7 Aniagenorlentiertes Anlagenbild in BAU- 
DIS NET (am Beispiel einer Druckmaschine) 
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BUd 8 Antriebsystem-orientiertes Anlagenbild in 
BAUDIS NET (am Beispiel einer Druckmascliine) 



3.2.2 Webbasierte Bedienoberfachen 

Die Information, die das oben beschriebene Diagnose- 
system zur Verfugung stellt, wird an vielen unter- 
schiedlichen Orten innerhalb und auBerhalb der zu u- 
berwachenden Anlage benotigt Da ist z3 der Ma- 
schinenleitstand mit dem BedarC an Daten fur den 
aktuellen Maschinenstatus, oder die Produktionslei- 
tung mit Bedarf an statistischen Daten zur Maschinen^ 
verfugbarkeit und Wartungszyklen. Aber auch der 
Maschinenhersteller bzw. der Antriebsausiuster muss 
auf jede ausgelieferte Anlage zugreifen konnen, um im 
Servicefell schnelle und effiziente Diagnose und Feh- 
lerbeseitigung zu gewahrleisten. Dabei ist es vollig 
uneifaeblich in welchmi Teil der Welt die Anlage in- 
stalliert ist 

Um all diese Forderungen zu erfuUen, ist der Einsatz 
von modemen Web-Technologien nahezu unabding- 
bar. Webbasierte Bedienoberflachen bieten aufgrund 
ihrer Flexibilitat gegenOber konventionellen OberQa- 
chen einige entscheid^de Vorteile: 



• a • 



• Die Weboberflache kann auf beliebigen Client- 
Rficbnem laufen (tmabliaiigig vom Client Be- 
triebssystem) 

• Eine Installation der BAUDIS NET Bedienober- 
flache auf dem Client-Rechner entfallt 

• Weboberflachen sind aufgrund ihrer weiten 
Verbteitung durch das Internet leicht bedienbar 

• Die BedienoberflMche kann mit veitretbaiem 
Aufwand an KundenwOnsche angepasst werden 
(Z.B. Sprachunterstntzung) 

Bild 7. tind Bild 8 zeigen zwei Weboberfladien, die 
die benotigte Infomiation fur den entsprechenden Be- 
nutzerkreis graphisch aufbereiten. 
Eist die Bereitstellung der richtigen Infoimationen 
(bezogen auf den jeweiligen Nutzer) zum- richtigen 
Zeitpunkt und am richtigen Ort» macht dieses Diagno-^ 
sesystem zu einem Instrument, dass die Maschinen- 
verfugbaikeit erhoht und auch komplexe Anlagen mit 
einer \^elzahl von Antrieben beherrschbar macht 
Wie Bild 9 zeigt, sind die an der Anlage aufbereiteten 
Infonnationen mit Hilfe von BAUDIS NET sowohl 
lokal als auch an einem beliebigen Ort vertugbar. 
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4 Zusammenfassung 

Cie oben beschriebenen Eigenschaiten der Baumiiller 
Sync-Drive Technologie kommen immer dann beson- 
ders zur Geltung, wenn es darum geht eine Vielzahl 
von Antrieben mit sehr hohen Anspruchen an Dyna- 
mik und Synchronitat za betreiben. Fur die Kommu- 
nikation durch die Ebenen der Automatisierungspyra- 
miede hat sich das Ethernet weitgehend als Standard 
durchgesetzt 

Nur durch die Nutzung der Starken der unterschiedU- 
chen Kommimikationsmedien ist es mdglich, den im- 
mer hdher werdenden Anspruchen in den jeweiligen 
Automatisierungsschichten gerecht zu werden. Wie 
gezeigt wurde, ist die Transparenz von der Leitebene 
bis in die Antriebsebene durch BAUDIS NET dabei 
vollstandig gewihrleistet 



Bild 9 Lokaler und weltweiter Zugriff auf die Di- 
agnoseinformallonen durch BAUDIS NET 
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Besprechung am 06,03.2002 bei Baumiiller 
Anlagen-Systemtechnik GmbH & Co. zwischen 
Harm PA G. Gbtz^ Herrn Meis und Herrn 

Tschaftary 

M: Ich kann Ihnen das auch mitgeben, denke ich. Dann haben Sie da 
auch noch eine Grundlage. Ja, worum geht's? Es geht um ein 
Diagnosesystem und wir merken einfach, dass die Anforderungen 
Immer hoher werderi. Ich habe hier mal so ein paar Anforderungen 
zusammengesteilt. Wir reclinen danDit, dass in den nachsten Jahren 
die Anzaiii von Antrieben, die wir diagnostlzleren sollen, wesentllch 
steigt in Richtung von 400, 500 Antrieben. 

G: Bisheriger Stand? 

M: 250. 

G: ZSOAritriebe. 

M: 250, 280. Das ist, glaube icli, im i^oment ein [Maximum. Und das 
erfordert naturlicli zum einen weit maclntigere Funktionen, das 
erfordert, dass wir auf dem Bereicln der Inbetriebnalime melir tun 
und so versuchen, eine Aniage sclineller in Betrieb zu nehmen und 
dass wir naturlicli aucii unsere Systemstruktur, die wir jetzt haben 
beim BAUDIS irgendwo anpassen miissen. 

G: Also, Sie verSndern jetzt die Systemstruktur auch? 

1^: Ja. Wir machen zwar grundsatzlich dasselbe. Wir haben viele alte 
Funktionen, eigentlich. Alle alten Funktionen, die wir im jetzigen 
BAUDIS haben, die werden wir auch im neuen BAUDIS haben. Fur 
den User schaut das genauso aus, aber wir realisieren letzten Endes 
ganz anders. 

G: Jetzt habe Ich mal eIne kurze Frage. Wir haben ja hier so ein grobes 
Blockschaltbild damals gehabt von dem BAUDIS. Sagt das Ihnen 
jetzt hier was? 

M: Das habe ich jetzt seiber noch nicht angesehen. 

G: Na, dann lassen wir das jetzt weg. Das ist jetzt nicht ergiebig. I^ich 
hatte jetzt nur interessiert, ob Sie dieses im wesentlichen 
. beibehalten. 
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M: Das zeige Ich Ihnen glelch/wie das dann ausschaut. Dann kSnnen 
wlr das gegenelnander stellen. Alsoy die Anforderungen steigen hier, 
wir haben auch noch die Anforderung hinzubekommen, dass unser 
Kunde diese Daten des Diagnosesystems auch noch mehr betrachten 
mochte und in einer Form zur Verfugung gestellt haben mochte, wie 
es fur ihn notwendig ist. Wir haben den weltweiten Zugriff des alten 
BAUDIS eigentlich auch schon. Und wir wollen, und das ist unser 
Ziel, letzten Endes dahin, dass wir neue l^ethoden und Funktionen in 
dieses BAUDIS hineinbringen, die uns eben helfen, die Antriebe 
besser zu Qberwachen. Fehler schneller zu finden, solche Dinge. Das 
1st also dieser ganze Strau6 von Anforderungen und ich, giaube so 
richtig interessant wird es eigentlich dann hier, weil hier sieht man 
jetzt mal die Struktur von diesem neuen System. Was naturlich alt 
Ist, ist die Antrlebsebene, d. h. also hier sind die ganzen Antriebe mit 
Ihren Reglern symbolislert.- 

G: Also „G'' heiBt Giga-Drive. 

M: Ja. . - . . . 

I ■ ■ • • 

G: Ach, so der ist jetzt Gfga, vorher war es |v|ega-Drive. 
T: Richtig, ja. 

M: Das ist jetzt ein Arbeitstitel. 

G: Was komm nacht Giga? Wissen Sie noch nicht. 

T: Tera, gibt es auch noch, oder? 

G: Tera- Drive. 

T: Das Giga leltet sich einfach davon her, dass der einen Prozessor hat, 
der Giga-Flops kann und von daher war das naheliegend, den TItel 
zu wahlen. 

G: „Flops^^ ist Abkurzung fur ... 

I « ■ ■ • 

O.k. Da gibt es also diese Antriebsebene, es laBt sich aber auch 
denken, dass hier andere Reglertypen von BAUMULLER drin sind, z. 
B. dieser b maXX, der neu entwickelt wird in der Elektronik, das Ist 
auch eine Neuerung gegenuber dem alten BAUDIS. Und um diese 
ganze Diagnose zu bewerkstelligen, haben wir filr jeden G-:Drive im 
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Moment einen Kommunikatlons-PC geplant. Also, PC 1st da zuviel 
gesagt. Also, das 1st einfach nur so ein klein.es Platinenmodul, wo ein 
Prozessor draufsitzt und das wird auf die Hardware des Reglers 
draufgesteckt. 1st aber ein vollwertlges Linux, so ein kleines Linux. 
Und nach auBen schaut es so aus, als ware es ein ganzer PC. 

G: Also, mit Gehause und so darf man sich das nicht vorstellen, mit 
eigenem Bildschirm, sondern. es ist bloB eine Elektronikkarte mit 
Prozessor drauf. 

M: Richtlg. ' 

G: LInux-Betrlebssystem. 

1^: RIchtig. A\so, nur so ein kleiner Typ mit einer Ethernet-Sciinittstelle 
und einer Schnittstelle zur anderen Seite. Und was wiederum gleicli . 
geblieben ist, wir haben iiier so eInen zentralen Rechner, den r 
nennen wir jetzt SAUDIS Application Server, hier sind allet 
. Funktionen,. die win so_fur die Diagaose und InbetriebnatimeJi 
brauchen, zu finden. Der ist angekoppelt an der Datenbank, die 
natOriicii auch auf diesem Rechner lauft. Also, da andert sicli jetzt so 
von auBen her nichts, bloB die Archltektur, das was da drfn steckt, 
das wird quasi vollig anders. 

G: Also, in diesem groBen blauen Kastchen jetzt auf der Seite 3 hler da 
Sndern Sfe Innen drin die Struktur. Von diesem sog. BAUDIS- 
Appllcatlon-Server. 

M: Ja. Vorher war das der BAUDIS-Server und jetzt nennen wir den 
Application-Server, um das ein biBchen zu unterscheiden und well 
das der landlSufige Begriff dafQr Ist. O. K. Und jetzt haben wir eine 
Reihe von Anwendungen hier auf dieser Ebene. Also, es sind 
verschiedene Anwendungen denkbar. Anwendungen, die so ein 
Antrlebssystem konfigurieren, die so ein Antriebssystem bedienen 
. Oder die diese Diagnose durchfuhren. Und wir konnen sowohl wenn 
wir vor der Aniage stehen als auch wenn wir uber das Internet Oder 
Telefon uns mit dieser Aniage verbindeh. Und das neue daran ist, 
das Ist ein wesentliches Merkmai, dass wir quasi die Oberbleche, 
also das, was der Benutzer sieht, und wo er seine Eingaben macht, 
trennen von der Funktlon, da wo es Implementlert Ist, vom Server 
quasi. 

G: • Und worin sind dann dIese Oberfiachenfunktionen implementlert? In 
welcher Hardware? 

M: Das lauft dann quasi auf einem separaten PC, also z. B. auf dem 
Leitstandsrechner von dieser Druckmaschine oder auf Irgend einem 
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anderen PC In einem Webbrowser. Also, das was Sie kennen als 
. Internet Explorer Oder Netscape Navigator, da kann man diese 
Oberflache aufrufen und kann alle Funktionen bedlenen, die hier auf 
dem Application-Server ausgefiihrt werden. 

G: Und da ist zwischengeschaitet ein Bus oder so was? An Ethernet ist 
ja im Prinzip ein Bussystem. Ist das richtig, ja? 

M: Das ist ein lokales Netz, wie wir liier auch haben. 

G: Ein lokales Netz. 

M: ... vernetzt sind. Lokales Netz mit Anschlu6 an das Internet, bzw. 
Qber Modem kann Ich mich dann hIer In dieses Netz einwahlen und 
. komme dann an diesen Rechner. 

G: Kann man das so ausdrucken: Sie lagern elgene Netzwerkknoten 
. aus, urn diese Bedlenoberflache zu realisieren? Das. helBt, fur die 
.. . Bedienoberflache. w^den Jnnerhalb . eines . Netzwerks elgene 
Netzwerkknoten ausgebildet. 

M: Hm, ja, das Ist etwas ungewShnllch formullert, aber ... 

G: Kann man mal so stehenlassen, vielleicht. Ich kenne es ja jetzt 
nicht. 

M: Also, es ist genau dieselbe Struktur wIe das, was Sie haben, wenn 
Sie eine Internetselte aufrufen. Wenn Sie jetzt auf „www.kugel.de'* 
Oder so etwas ... 

G: Auf „www.kugel?" 

M:- „kugel.de" Oder irgend etwas, was Ihnen einfallt. „telekom.de" oder 
so etwas. Dann rufen Sie ja eine Seite auf und der Inhalt dieser 
Seite wird abgerufen von so eInem Server. 

G: Ah, ja. Und Sie ubernehmen jetzt quasi das Intern etmodel I. 

M: RIchtIg, ja. So kdnnte man das sagen. 

G: Und dann ist der BAUDIS-Application-Server der zentrale Server und 
Ich rufe quasi dessen Internetadresse auf oder dessen 
Netzwerkadresse auf. . . 

M: Ja, dessen Netzwerkadresse und dann ist das quasi genauso wie 
. wenn Ich so eine Seite von der Telekom aufrufe. Grob verelnfacht, 
kSnnte man das so sagen. • 
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G: Und das sind das hier die Clients, Oder was? So nennt man. das, 
glaube Ich, bei Ihnen? 

1^: RIchtig, das sind dann die Clients und das 1st der Server.. Und wir 
mussen das nicht unbedingt uber das Internet machen bzw. uber 
eine jv^odemverbindung, wir konnen das naturlich aucli machen, auf 
alien Rechnern, die jetzt hier im Netz angeschlossen sind. 

G: Und bisher waren diese Funktionen Diagnose, Bedienung, 
Konfiguration, die hier uber das Ethernet an den Server 
angeschlossen sind Im Server selber integriert, sind dort abgelaufen. 
Und ich habe keine Ethernetkommunlkatlon dazwischen gehabt. 

T: Nicht zur Fernbedienung, naja, jeln ... 

M: Poch, doch das hatten wIr elgentllch schon. Doch wIr hatten das', 
elgentlich schon. Im Normalfall ist das so, dass derjenige, der dasfi 
BAUDIS bedlent, an diesen Rechner geht. WIr haben aber zusatzlichJ^ 
die MSglichkelt der Ferndiagnose. Deswegen haben wIr dieses 
System ja entwickelt, nSmllch dass wir uns z. B. vom einem 
entfernten Rechner, z. B. von dem hier Im BQro iiber eIne 
Modemverblndung an diesen BAUDIS-Rechner anhangen konnen 
und dann auch dasselbe tun. 

G: Das war mat hier fruher so ahnlich, aber ich habe schon fast das 
Gefiihl, ob das Oberhaupt so richtig gestimmt hat mit dem realen 
BAUDIS. Das BAUDIS- Patent, das Ist auch die Frage. Das war 
wahrscheinlich ganz In den Anfangsgrunden und so und dann hat es 
sich jetzt schon sehr stark von dem Patent wegentwickelt. Gut. Dann 
bleiben wir bei Ihnen, Ich glaube, das Patent hier ist gar nicht so 
hllfreich. 

T: Unterschiedllch ... Ist das hier schon ein Unterschled zu dem 
Application-Server und zu dem hier oben, glaube ich, dass der 
entfernte PC sogar jetzt genutzt wird, halt auch die BAUDIS- 
Appllkation haben muBte, die hSngt auf diesem entfernten System. 
Und das ist hier nicht mehr notwendig ... Und das ist der 
entscheidende Untei^chied. 

G: Ach, so. Die Applikatlon lauft jetzt nicht mehr auf diesem 
Netzwerkknoten fCir den Bedlener selbst, sondern der 
Netzwerkknoten ruft sIch, immuliert (?) die Applikatlon, kann man 
das sagen? 

T: No, no. Der kriegt einfach Daten. ... 
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G: Also, genau so, wie wenn der Internetnutzer eine Website aufruft. 
M: Richtig. 

G: Das Model ubertragen Sle jetzt hierauf. 

M: Genau, ja. Das bletet uns eben Flexibilitat, das bletet uns, dass wir 
dem Kunden die Informationen anzeigen konnen, wo er es mochte. 
Ohne dass wir auf dem PC, wo er es mSchte, Irgend etwas. 
installieren mOssen oder irgendwie den verandern mussen, oder so 
was. Sondern wir sagen eben: Du brauchst bloB so einen 
Internetbrowser haben, dann meldest Du Dich hier an und dann 
kriegst Du die ganzen Informationen. Das ist quasi fur den Nutzer so 
das Entscheidende. Also, in der Struktur neu ist dieser 
Kommunlkations-PC, neu ist die Trennung von OberflSche und 
Server. 

G: Die Oberflache die bilden jetzt einzelne Netzwerkknoten, Clients,*! 
Client- Knoten, . die. dann Qbec . das Ethernet mit dem. Servec^' 
verbunden sind. 

1^: Ja, denke Ich, das kann man so sagen. 

G: Dieses Blld steht dann fur die Patentanmeldung, ist das vielleicht 
ganz gut, ganz brauchbar. 

M: Wenn wir dann so weit kommen, dann konnen wir das naturlich 
verwenden. Ja und jetzt, ich wei(3 nicht, inwieweit das jetzt Sinn 
macht, aber noch einmal ein biBchen hineinzuschauen in diese 
einzelnen Komponenten hier, was wir hier neu haben. 

G: Je mehr I^erkmale wir haben, um so mehr Sicherheit haben wir fur 
eine Patentanmeldung und bessere Chancen. 

M: Vielleicht sollten wir das einfach mal kurz machen. Wir schaueri jetzt 
mal in diesen Kommunikations-PC hinein, was da drin abiauft. Dieser 
Kommun!kations-PC hat quasi die Aufgabe, alles was an den Regler, 
der hier oben jetzt nicht gezeichnet ist, aber hier oben wurde man 
ihn dann sehen, alles was an die Regler an Informationen geschickt 
werden muB oder vom Regler an Information geholt werden muB, 
abzuwickeln. Also, Kommunikation eriedlgt er. Und da gibt es 
verschiedene Dinge, die ubertragen werden mussen. Fangen wir mal 
mit diesen belden Kasten an hier, das ganze ist also eine modulare 
Softwarestruktur, also alles was man hier sieht symbolisiert ein 
Stuck Software, was auch im Windows- Betriebssystem laiuft. Und 
hier gibt es also- zwei Softwaremodule, die eriedigen die 
Kommunikation mit der Steuerung, also Irgendwo mu6 ja dIese 



Gotz & Kuchler 
Patentanwalte 
B005/039 P DE/28-mt 



7 



•13.03.02 



Maschine auch gesteuert werden und dazu mussen spezielle 
Sollwerte und andere Parameter ubermittelt werden und das wird 
von diesen beiden Modulen eriedigt. Die nennen wir Request- Broker. 
Broker deswegen, well sle Informationen austauschen, von hier von 
diesen Clients, also das ware In dem Fall entweder dieser BAUDIS- 
Appllcatlon-Server, der 1st jetzt gegenCiber dem natOrlich als Client 
aufzufassen, well er ja von dem was will und in diesem Fall hier ware 
das die Steuerung. Die Steuerung mochte nSmllch auch unserem 
Regler sagen, bitte ... 

G: Die Steuerung haben Sie hier, glaube Ich, auch aufgezeichnet. 

M: Habe Ich hier aufgezeichnet, aber In einem anderen Zusammenhang. 

G: Hat die dann eine direkte Verbindung zu so ' einem 
Kommunlkatlons...? 

M: Neln. 

G: Hat sle nicht. Das geht uber Server. 

M: Das ist hier ein anderer Zusammenhang. Damit 1st jetzt nIcht die 
Steuerung gemeint, von der Ich jetzt gerade ... 

G: Ach, so! DIese Steuerung auf Seite 3 hat nichts mit der Steuerung 
von der Seite 17 zu tun. 



M: Man konnte das auch hier im ersten weglassen und rriuBte dann 
nSher, warum es dann hier Ist. 

T: Und die hat dann durchaus Zugang direkt zu dem PC. 

M: Ja, ja. Genau. Also x)Ie Steuerung wSre eine von diesen Clients, die 
was von diesem Kommunlkatlons- PC wollen und die schlckt Ihm uber 
diese beiden Module Sollwerte. „Fahr mal so schnelP oder >,mach 
mal dieses, mal jenes". Und jetzt haben wir hier diesen roten 
Broker, den nennen wir Parameterschnittstelle. Dazu muB man 
sagen, dass unser G-Drive elgentlich nichts welter verstelit als 
Parameter. Der hat einen Satz von ungefahr 1500-2000 Parametern 
und uber diese Parameter kann man alles einstellen. Alles, was man 
mit diesem tun kann, muB man Qber Parameter einstellen. Und 
dieses Softwaremodui ist Ciber eine Schnittstelle hier mit dem G- 
Drive verbunden und kann Parameter lesen und schrelben. 
Wesentllch mehr kann es nicht. Also wenn Irgendelner dieser Clients 
hier irgendelnen Parameter lesen mochte oder eine Gruppe von. 
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Parametern, dann bedient er sich dieser Parameterschnlttstelle hier. 
Er gibt quasi den Auftrag und sagt „Ich mochte jetzt den Parameter 
4711 und 4712 mochte ich lesen'\ dann wird hier ein 
entsprechender SoftwareprozeB gestartet, der fordert jetzt diese 
Parameter von dem G-Drive an, der G-Drlve schickt sie ihm und 
dieser Request-Brol<er gibt sie dann weiter an den, der das 
aufgerufen hat. So hat man sich das vorzustellen. Und man l<ann mit 
diesem Request-Brol<er auch noch andere Dinge machen. Man l<ann 
dann sagen, ich mochte den Parameter 4711 im Sel<undenabstand 
geschicl<t bel<ommen. 

G: 1st das was neues, dieser Kommunil<ations-PC, diese Karte?. 
M: 3a. 

G: Dann muBte man da wahrscheiniich einen eigenen Patentanspruch 
Oder so was da draufsetzen, dass man den fur sich genommen aliein 
schon geschOtzt hat. NatQrIich dann auch im Hlnblicl< auf das 
. . Gesamtsystem aber auch, schon. ohne das Gesamtsystem, eventuelici 
Gut, das denl<e ich mir jetzt nur so, wle" man das eventuell 
l<onzipieren l<6nnte fiir eine Patentanmeldung. 

1^: Gut. Dann gibt es noch eIn paar andere l^odule hier. Ich weiB nicht, 
Ob es Sinn macht, die alle zu eriautern. Dieser hier kiimmert sich z. 
B. um Fehler. Jetzt ist es ja so, die Hauptaufgabe von dem 
Diagnosesystem ist, schnell rauszubekommen, wann wo der Fehler 
auftritt an so einer Aniage und dieser Request- Brol<er ist dafQr 
zustandlg. Der l<uckt also Immer bestimmte Parameter, die man 
eben l<onfigurieren l<ann, nach und schaut, ob da ein Fehler 
aufgetreten ist. Und wenn eln Fehler aufgetreten ist, dann meldet er 
denjenigen, die sich dafur Interessleren, dass so eln Fehler oder ein 
Ereignis aufgetreten Ist. Und das neue oder das schone an diesem 
Broker ist, dass ich den halt frei konfigurieren kann. Ich kann mir 
bellebige Fehler oder beiiebige Ereignisse konfigurieren. Ich kann 
sagen, also wenn der Parameter X auf 10 steht, dann mochte ich 
das wissen. Und dann sagt er mir das. 

G: Also, wenn wir das Blldchen bringen, miissen wir schon alle Kasten 
erklaren. 

M: Naturlich. Ich versuche jetzt blo6, das Notwendigste zu erklaren, 
damlt wir da nicht durcheinander kommen. Das ist also jetzt eine 
modulare Softwarestruktur. Man sleht z. B. hier noch, dass dieser. 
Broker von der Steuerung nicht direkt auf den G-Drive zugreift, da 
fehlt ja die Linlfe, sondern' der bedient sich im Prinzip dieser 
Parameterschnlttstelle, um darauf zuzugreifen. 
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G: Ach, ja. Das 1st ein biBchen codiert gezeichnet. 

M: Also, hier diese rote Linle da, die wird quasi zu jedem ... Also jeder 
kann diese Para mete rschnittstelle ... well ietzten Endes mSchte die 
Steuerung auch bloB Parameter lesen und schreiben. 

G: Braucht man vielleicht auch weniger Verkabelung. 

M: SoftwaremaBige Verkabelung braucht man weniger, genau. Und der 
Vortefi 1st halt, dass Ich hier diesen Block nur ein einzlges ma! 
schreiben muB. So muBte Ich jetzt das, was hier drin steckt, hier 
schreiben und hier schreiben und hier schreiben und hier schreiben 
und dann sage ich einfach, O. K. dann mache ich einen eigenen 
Dienst daraus und jeder, der eben so einen Parameter lesen und 
schreiben mochte, der muB eben sich dieses Dienstes bedlenen. 

G: Das sind alles nur Softwaremodule. Das iauft auf diesem Prozessor>. 

das ganze graue 1st der Prozessor, der hier diese Software mW 
.. . S-elnemAnbeltsspelcher und Programmspeicher drinnen.haL_So kanfi^ 

man sich das vorstellen, ja?! 

M: Das ist hier diese Unux. Der Linux-PC, quasi und da laufen diese 
ganzen Softwareprozesse. Also, wie auf dem normalen PC auch, 
dann konnte man sich vorstellen, da Iauft ein Word und ein Excel 
und ein Outlook oder so ahnlich ist das hier auch. Das sind hier 
verschiedene Prozesse, die alle eine bestimmte Aufgabe haben und 
die mitelnander kommunizieren. 

G: In was fur einer Sprache programmieren Sie das? 

M: Das programmieren wir In C. 

G: In C? 

1^: . Ja. Vielleicht eIne Sache vom Gedanken her, die auch noch neu ist. 
Wfr mochten hier bestimmte Funktionen, die wir vielleicht jetzt nicht 
durch diese Funktionen, die hier implementiert sind, realisieren 
konnen, auf diesen Kommunikations-PC bringen. Also, wenn wir jetzt 
einen Fehler suchen und wir feststellen, mit dem was wir hier so drin 
implementiert haben, kriegen wir den Fehler nicht raus, dann muS 
man eine komplizierte Bedingung formulieren, bei der man dann 
Daten bekommt oder irgendwie so was, dann wollen wir das mit 
solchen Skripten machen. Das sind also klelne Programme, die man 
sich schnell schreiben kann in einer einfachen Sprache und die kann 
man dann auf diesem Kommunikations-PC laden und kann die" 
. Funktionaiitat, die hier zur Verfugung steht, noch einmal erweitern. 
Ich kann also dann noch komplexere Uberwachungsfunktionen 
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wahlen. Das 1st die Bedeutung hinter diesem Kasten. Und da glbt es 
noch einen grunen Kasten, da steht „Webserver'' da, das ist jetzt 
nicht zu verwechsein mit dem, was wir fiir den Application-Server 
gesagt haben, das konnte so ein klelner Webserver sein, so ein 
klelner MInlwebserver auf diesem Kommunlkatlons-PC sein und der 
konnte eine kleine BedienoberflSche zur VerfQgung stellen. Das 
helBt, wenn ich also jetzt kein SAUDIS habe und kein groBes 
Antriebssystem, sondern ich habe nur so eInen Regler mit so einem 
Kommunikations-PC, kann Ich mich da dranstopsein und kann die 
. Parameter lesen und schrelben oder Irgendwelche anderen. 

G: Kann man auch weglassen den Webserver. 

_ 1^1: KSnnte man auch weglassen. 

G: Welche kann man nicht weglassen von diesen Blocken hier? 

M: Also, fQr unsere Funktlon, damit die Aniage lauft, brauchen wir dle^e 
. : . . ._ beiderL ... .... . .... 

G: Also, wir brauchen Request-Broker. 

M: Einmal fur Bedarfsdaten und bezQgllch der Sollwerte. 

G: Also, zwei Request-Broker, einmal fur Parameterbedarfsdaten und 
einmal fur bezugllch der Sollwerte. Dann brauchen wir noch mehr? 

M: Dann brauchen wir das, was hIer Ist. 

• G: Die drei Blocke noch welter. Das Ist also ein Request-Broker fiir 
Fehler und Events, fur Parameterschnlttstelle und das letzte 1st fQr 
Softwaredownload. DIese funf Broker sind unabdlngbar. 

M: Hm. 

G: Also, die machen diesen Kommunlkat!ons-PC aus. Das sind die 
wesentllchen Funktlonselemente. 

M : Elgentlich Ist nur der Webserver das einzlge, was man weglassen 
kSnnte. 

G: Ach, so. 

M: Das gehort elgentlich alles zusammen. 



G: 



Ja. Also letztlich ist nur der Webserver optional. 
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M: Ja. 

G: Es geht halt darum, dass man vielleicht eine Erfindung aus diesem 
KommunikationsrPG definlert, dass man dann nur die notwendigsten 
Merkmale hat, damit man das also moglichst wenig umgehen kann. 
Deswegen frage ich da. Das helBt, wenn man hiervon was weglaBt, 
dann funktionlert das alles nicht mehr, von diesen fQnf Brokern 
belsplelswelse einen, dann ... 

T: ... komplette Aufgabe, so . wie er . beschrieben hat, ais 
Kommunikatlons-PC kann er dann nIcht mehr erfullen. Dann geht es 
halt nur In Tellberelchen. 

G: Gut. Was haben wir noch fOr wesentllche Funktlonskomponenten 
auBer Kommunikations-PC? 

M: Jawohl. Dann schauen wir noch einmal auf dieses Bild und kucken 
ma! In diesen Application-Server. 

G: BAUDIS-Application-Server kommt jetzt. 

M: Hfer sleht man jetzt also noch einmal diese Antrlebsebene, die wir 
gerade gesehen haben, diese Kommunikations-PCs, das, was wir 
gerade angesehen haben, hier symbollslert diese kleinen Request- 
Broker, die jeweils Informatlonen zur Verfugung stellen. 

G: Jetzt sind es nur noch vier. 

1^: Jetzt sind es nur noch vier, richtig. Wenn ich, genau, eigentiich, eins, 
zwei, drei, vier. Weiie diese beiden komrhunizieren mit der 
Steuerung. Und die Informatlonen von und zur Steuerung, die haben 
wir ... 

G: Ich sage es jetzt fur das Band. Also, die beiden Request-Broker 
Parameterbedarfsdaten und zyklische Sollwerte sind dann auf der 
Selte 13 be! dem Kommunikatlons-PC weggelassen, well diese nur 
mit der Steuerung kommunizieren. 

M: Richtig. Hier diese Kommunikations-PCs bis zu 500 StQck, sage Ich 
mal, und dann sleht man hier diesen Application-Server, schauen wlr 
uns gleich naher an, und hier die verschiedenen Anwendungen. Hier 
sind mal zwel Anwendungen gezeigt. Diese ist die Hauptanwendung, 
hier sehen Sie diesen Webbrowser, also Internet Explorer oder 
Netscape, und hier quasi symbollslert die Oberflache, also die 
Webseiten, die dann zur Verfugung stehen fiir den User. 
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Jetzt schauen wir mal rein, was in diesem Application-Server drin 
ist: Aucli wieder. analog zu denn, was im Kommunil<ations-PC abiauft, 
eine modulare Softwarestrulctur. Wir wolien ja in der Lage sein, das 
spater mal zu erweitern Oder einzelne [Module auszutauschen. Sie 
sehen also hier vier Module gezeichnet, von denen es durchaus auch 
noch mehr geben kOnnte. Also, wenn Ich noch neue Funktionen 
brauche, wenn Ich z. B. einen neuen Reglertyp, wie z. B. den 
b maXX von BAUMULLER unterstutzen mochte, brauche ich so ein 
neues Modul. 

G: EIn neues Servermodul b maXX. 

M: Zum Beispiel. 

G: Anstelle von G-Drlve. 

M: Oder zusatzlich. Das sind also jetzt in diesen Modulen, da steckt 
jetzt die gesamte Funktion drin. Und um diese Funktionen, die wir 

. ._ hier jmplemejntleren nach auBen.zur Verfiigung zu_stellen,.bra.uchen 
wir einen Webserver. Weil wir gesagt haben, wir wolien hier mit 
einem Webbrowser kommunlzieren und Internetseiten zur 
VerfQgung stellen, also brauchen wir einen Webserver. Das Ist eIn 
handelsubliches Ding, was man so hier verwendet. Weiterhin 
brauchen wir noch einen FTP-Server, damit konnen wir Dateien 
austauschen. 

G: FTPhelBt? 

M: File Transfer Protocol. Und wir brauchen noch einen Telnet-Zugang. 
Das ist quasi eine MSglichkeit, um aus der Feme Wartungen Oder 
Einstellungen an diesem PC hier vorzunehmen. Also hier Ist wieder 
nur die Software gezeigt, aber was darunter liegt, Ist nattirlich ein 
ausgewachsener Server-PC, also irgendein Internetprozessor, so wie 
sie. hier so stehen. Was sInd jetzt nun die einzelnen Aufgaben dieser 
Module? Hier dieses Servermodul G-Drlve. Ich blatter mal um, well 
da sehen wir jetzt noch einmal das Innere von diesem Application- 
Server.. Ich denke, Sie konnen sich das jetzt vorstellen, das Ist also 
quasi der Innere Kasten. Alles, was da drin Ist ... 

G: Das Ist BAUDIS-Server? 

M: BAUDIS-Applicatlon-Server. Sieht man also hier noch einmal groB 
gezeichnet dIese Servermodule hier und der Webserver und Telnet 
und. FTP. 

G: Hier sind es vIer, hier sind es wieder fiinf. 
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M: Hier slnd es funf, weil hier ist z. B. dieses Servermodul b maXX noch 
zusatzlich gezeichnet. Aber da wissen wir noch nicht genau, wie das 
aussleht. Deswegen ist das hier nur leer. Und bei manchen Sachen 
wissen wir noch nIcht so ganz genau, was da alles rein kommt. Da 
sind wir eben jetzt gerade am Uberlegen, aber diese Sachen sind 
schon relativ sicher. Servermodul G-Drive: Wie der Name schon 
sagt, das eriedigt quasi alles, was mit dem G-Drlve und der 
Kommunilcation mit dem G-Drive zu tun hat. Alles was G-Drive 
spezifisch ist. Das Servermodul b maXX wurde alles eriedigen, was b 
maXX spezifisch ist. Hier ist diese Parameterschnittstelle zu nennen. 
Wir haben ja am Kommunikations-PC gesehen, es geht eigentlich 
nur um Parameter lesen und schreiben, hier diese Funktion 
Softwareupdate zu sehen, wir wollen ja irgendwie auch die Software 
fur den Regler auf den Regler bringen. Bisher haben wir das immer 
so gemacht, dass wir das quasi von Hand dahintransportiert haben, 
also wir haben das auf so eine kleine Karte draufgespielt und die 
Karte reingesteckt und dann den Regler neu gebootet und dann war 
die Software drauf und jetzt wollen wir das so machen, dass es quasi 

.. - auf Knopfdruck geht. Dass wir hier eine Funktion haben, und sal^ru . 
„druck drauf und dieser Regler wird mit einer neuen Software 
versehen'\ Aber die Funktionen, die wir dafiir brauchen, den 
Program miercode, den man schreiben mu6, der Ist hier in diesem 
Servermodul drin. Ja und da sind noch so ein paar andere 
Funktionen. Die nennen sich Datensatzerstellung, Datensatzup- und 
download. Wir nennen diese Parameter oder bestimmte Gruppen 
von Parametern nennen wir Datensatze. Die sind fur die Funktion 
des Reglers entscheidend und diese Datensatze kSnnen wir hier 
editieren und auf den Regler schlcken oder wieder vom Regler laden. 
Und dann haben wir noch so eine Funktion die nennt sich 
Antriebsichern. Hier konnen wir quasi ein Image, also ein den 
Zustand des Reglers, Softwarezsutand des Reglers abspeichern und 
daran konnen wir Anderungen vornehmen und wenn wir dann 
feststellen, das war wohl doch nichts, dann konnen wir diesen 
Zustand wieder zuruckschrauben und das ist genauso wie vorher. 
Die Funktionen, die man dafQr benStigt, sind da drin. Das Ist G-Drive 
spezifisch, das ist b maXX spezifisch und alles, was man hier sieht, 
ist jetzt nicht mehr reglerspezifisch. Hier ist eine 
Servermoduldiagnose, hier tauchen diese Fehler und Alarme wieder 
auf, von denen ich beim Kommunikatlons-PC gesprochen habe, wir 
hatten ja diesen Request-Broker Fehler und Events, der Fehler zur 
Verfugung stellt, wenn also ein Fehler auftritt, dann informlert er 
mich, und das ist quasi das Gegenstuck dazu. Also der nimmt die 
Fehler entgegen bzw. der konfiguriert den Broker auf dem 
Kommunikations-PC und sagt ihm, auf welche Fehler er reagieren 
soli Oder auf welche Ereignisse er reagieren soil. Hier ist eine 
Langzeitaufzeichnung gezeigt, wir wollen z. B. fur Analysezwecke 
bestimmte Parameter Qber viele Stunden oder viele Tage 
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aufzeichnen und die dann hinterher graphisch anschauen und das ist 
dann hier noch, und dann kSnnen sicherllch noch ein paar Sachen 
dazukommen. Das Servermodul Anlagenkonfiguration: WIr mussen 
ja, wenn man jetzt an den Aufbau und die Inbetriebnahme einer 
solchen Aniage denkt, muB man ja erst mal die Konfiguration der 
Aniage irgendwie In dieses Systenn hineinbekommen. Also 
Konfiguration, damit melne icii jetzt: Da ist jetzt ein Druckturnn und 
da ist nocli ein Druckturm und das ist noch ein Druckturm und da ist 
ein Falz und da iiabe ich jetzt an jedem Druckturm so und so viele 
Antrlebe. Das muB ich ja Irgendwo mal einrichten, damit Ich dann 
mit diesem System arbeiten kann und das findet in diesem Modul 
statt. Da haben wir also ein Aniagenbild, Ich weiB nicht, ob Sie das 
BAUDIS schon mal in Echt gesehen haben, da gibt es also ein 
Aniagenbild, da werden alle Antrlebe dargestellt, ich kann Ihnen da 
mal kurz einen Ausschnitt davon zeigen, wie man sich das vorstellen 
kann. Wenn Sie noch einmal diesen Ausschnitt betrachten hier, dann 
sieht man hier so ein Aniagenbild, das ist also eine symbollsche 
Darstellung. Hier sieht man so verschledene Druckwerke urtd^hier 
...sleht man Motoren und immer wenn da eiaPehler auftritt, dar:^ngt 
dieser Motor an zu bllnken. Und da kann also der Drucker oder der 
Bedlener hat da den Uberblick uber seine Aniage und sieht sofort, 
hier ist ein Fehler aufgetreten, hier ist irgend was passlert, hier muB 
ich darauf reagieren. Und um dieses Ahlagenbild zu erstellen, und 
die notwendlgen Adressen und notwendlge Konfiguration hier ... 

G: Aber.das paBt nicht zusammen. 

M: Ach, Gott. Um das vorzuhalten, dafur brauche ich dieses 
Servermodul. Ich denke, wir haben es auch eigentlich gleich. Eine 
IWInute brauche ich noch. 
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Anordnung und Verfahren zur Fehler-Diagnose und/oder -Analyse eines 
Oder mehrerer technlsch-physlkalischer Prozesse, insbesondere elektrl- 
scher Antriebsvorgange, die unter der Steuerung, Regelung und/oder 
Obenwachung durch einen oder mehrere ProzeBrechnerknoten ablaufen, 
wobei uber wenigstens einen gemeinsamen Bus die ProzeBreclinerknbten 
mit wenigstens einem Diagnosereclinerknoten verbunden sind, in dem eine 
Oder mehrere Diagnosedienste und/oder -funklionen implementiert sind, die 
dem Oder den Prozessen und/oder dem oder den ProzeBrechnerknoten 
und/oder den darin ablaufenden .Ye/arbeitungsprozessen zugeordr^t sind, 
gekennzelchnet durch den gieichzeitigen Efnsatz asynchroner und syn- 
chroner Kommunikatlonssysteme auf Leit- und Steuerungsebene, wobei die 
Sollwertvorgabe asynchron von der Leitebene erfolgt. 
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